Celestin Apprentice 5/Apprentice-Release5.iso/Information/THINK C Digest/1992/92-01

Text File | 1995-12-31 | 126KB | 3,654 lines

Path: ucivax!gateway
From: [e-mail] ("Eric W. Sink")
Subject: Are direct classes useful ?
Message-ID: <[e-mail]>
X-Mailer: ELM [version 2.3 PL11]
Newsgroups: fa.think-c
Lines: 20
Date: 1 Jan 92 21:04:51 GMT

I want to create a special hierarchy of classes for my application.
Objects for this set of classes will always be allocated in a
special region of memory, for efficiency, and the classes therefore
need to be direct.  Object references will be pointers to some
portion of some locked pool of memory.

Then I found out that subclasses cannot change the access specifier.
Therefore, my hierarchy cannot be subclassed from CObject.  Therefore,
I cannot store objects from my hierarchy in CLists or CStacks.

It would appear to me that if I want a hierarchy of direct classes,
I must then write my own hierarchy of Collection classes to support
the new objects.

Anyone have any insight ?

--
Eric W. Sink,  Spatial Analysis and Systems Team
USACERL, P.O. Box 9005, Champaign, IL 61826-9005
1-800-USA-CERL x449,   [e-mail]










Path: ucivax!gateway
From: [e-mail] (Alan Piszcz)
Subject: MAILING list addition?
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 6
Date: 2 Jan 92 11:43:34 GMT

To whom it may concern:

Can you please add me to your mailing list?

Thank you.











Path: ucivax!gateway
From: [e-mail] (David Sugar)
Subject: A5 ???
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 18
Date: 2 Jan 92 13:18:27 GMT


  Ok, I've sorta been asking questions leading up to this in the past couple
of weeks, but now I'm stuck again.  Here is what I'm doing??  I want to
write a background only appe that runs on startup, but I want it to use
PPC to be able to communicate to other apps (either local or network).  The
PPC isn't a problem, and I can write the appe, but I can't seem to get it
to register it's self when I start it as an appe in the extensions folder.
I know that it is running because something like Process Watcher or Tattle
Tale will show me that it has a process, but it doesn't register under PPC.
I've been doing some reading and looking through code and from what I have
found I think that I need to make an A5 world??  Am I correct in thinking
this, will this help, am I making any sence??  If anyone has either some
code or suggestions on how to do something of what I'm trying, let me know??

Thanks

Dave Sugar
[e-mail]










Path: ucivax!gateway
From: [e-mail] (Wade Williams)
Subject: Think C build order
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 40
Date: 3 Jan 92 00:24:53 GMT
X-Envelope-to: [e-mail]

Ok, this should be a simple question:

I've asked it on Compuserve, but I want to see if anyone out there has any
innovative ideas.

As I'm sure most of you know, THINK Pascal allows you to change the build
order of files in the project.  Thus, with the "uses" statement, the last
file in the project can use a procedure or variable declared in the first
file of the project.  In particular, I've used this feature to create a
"Globals" unit that contains all my global variables and procedures.

However, THINK C insists that files be built in alphabetical order.
#including a globals.c file doesn't work because the variables get
redeclared in every file (even using the #pragma once).

One suggestion is to put all the variables in a global file and have THAT
file #include all the other files in the project.  However, someone
mentioned that this "wreaks havoc" on incremental compiles.  Why, I'm not
sure - can anyone verify this?

So my questions are:

1)  How can I create a file of global variables that will be available to
all files in the project?

2)  If I want to call a procedure in another file, is simply #including the
file all that is required?

BTW, this is using THINK C 5.0.1.

Thanks.

-------------------------------------------------------------------------
Wade Williams                             "Any escape might help to smooth the
User Services Specialist            unattractive truth, but the suburbs
Academic Computing                     have no charms to soothe the restless
Auburn University                      dreams of youth." (N. Peart)
[e-mail]
-------------------------------------------------------------------------











Path: ucivax!gateway
From: [e-mail] (Peter Miller)
Subject: Re: Think C build order
X-Face: u\%{\QY_5[S37dfQ#c*#""=K,KGq>4wGryNm+=TT]1jOGap~>j*-sb9d|ll.sHIJu&n{:T`
 cP|e(B?o,W%l_)o5pW,"MVie?sw{hZ@7E^o`C:wz){1p!u%O<N#lcPP]b|f:2,-mNKt{Ue(_7e"ok@
 b".~TQ#YGrlY[r!:5q[/"O&Bn4:3mwuUFt>Qc]KTq}A")Jk,[
Message-ID: <[e-mail]>
In-Reply-To: Your message of 03 Jan 92 00:24:53 +0000.
             <[e-mail]>
Newsgroups: fa.think-c
Lines: 136
Date: 3 Jan 92 03:49:05 GMT


Wade Williams <[e-mail]> writes:
> Ok, this should be a simple question:
>
> I've asked it on Compuserve, but I want to see if anyone out there has any
> innovative ideas.
>
> As I'm sure most of you know, THINK Pascal allows you to change the build
> order of files in the project.  Thus, with the "uses" statement, the last
> file in the project can use a procedure or variable declared in the first
> file of the project.  In particular, I've used this feature to create a
> "Globals" unit that contains all my global variables and procedures.
>
> However, THINK C insists that files be built in alphabetical order.
> #including a globals.c file doesn't work because the variables get
> redeclared in every file (even using the #pragma once).
>
> One suggestion is to put all the variables in a global file and have THAT
> file #include all the other files in the project.  However, someone
> mentioned that this "wreaks havoc" on incremental compiles.  Why, I'm not
> sure - can anyone verify this?
>
> So my questions are:
>
> 1)  How can I create a file of global variables that will be available to
> all files in the project?
>
> 2)  If I want to call a procedure in another file, is simply #including the
> file all that is required?
>
> BTW, this is using THINK C 5.0.1.

Dear Wade,

You prombelm is not unique to Think C.  Tha advantage, and disadvantage, of C
is it allows you to do just about anything you like.  So writing
portable code, and read able code, and any other type of code, means
self-discipline in C, because the language doesn't do the discipline for you.
Tools not rules, as the X11 guys say.

The simplest transition for PASCAL programmers,
and a hugely useful programming model in any case,
is to make the following equivalences:
    UNIT fred
    INTERFACE
        something    <- fred.h
    IMPLEMENTATION
        something    <- fred.c

anywhere in PASCAL you would have said
    USES fred
you say
    #include "fred.h"
in C.

Because the .h file and the .c file are independent,
the compilation order doesn't matter.

The only thing to remember is to put
    #include "fred.h"
at the top of fred.c, so that the prototypes and delarations in fred.h
and be verified to be the same as the definitions in fred.c, by the compiler
automagically.

In order to gave a file of global variables
the "globals.c" file would looke something like this:
    #include "globals.h"
    int foo;
    int bar;
    int baz;

    double
    sqr(double x)
    {
        return x * x;
    }
and the "globals.h" file would look something like this:
    extern int foo;
    extern int bar;
    extern int baz;

    double foo(double);
Note that the "extern" is implicit on function prototypes.
You should also be aware that "extern" means "this guy exists, but is
defined somewhere else".  There may be many extern declarations of
the same variable, but only one definition in the entire program.

In particular, the following code is legal:
    extern int foo;
    int foo;
which is what is actually happening in the #include "global.h" inside of
thr "global.c" file.  Subsequent declarations of a variable (or function)
are verified to be consistent with earlier declarations.

The reason that PASCAL has a build order is that the compiler constructs
a compiled form of the INTERFACE section.  You can't USES it until this has
been done.  Not so with C, where the .h file exists in its own right.

So what should go into a .h file?
Exactly as much as is necessary to interface with the code in th .c file.
No more.  (And obviously no less, or it is unusable.)
In particular, if you can keep a symbol private to the .c file, do so,
otherwise you clutter the name space and get irritating errors.
[When writing libraries this is even more important, as users can't
be psychic and "know" what random symbols you are going to lob into
the various name spaces.  The naming convention, below, helps this too.]

Another parallel is the use of static variables and functions.
These are analogous to variable and function definitions
inside the IMPLEMENTATION section and not memtioned in the INTERFACE section.
Use them for the same reasons.

Another convention I use is that EVERYTHING defined in fred.h has a
fred_ prefix.  That way, if I'm looking at a use of fred_disembowel,
i know (KNOW!) that it is in fred.c.  Also, i know (KNOW!) none of the
symbol names in fred.h will collide with any other symbol in any other file.
Naturally the restriction only applies to .h files,
anything static to the .c file is not so restricted.

Re-reading the original questions prompts another suggestion,
obvious to a long-time C programmer, but not so obvious to a beginner:
    The file suffixes .c can be thought of as "dot code" and the
    suffix .h as "dot header".
Only .h files are ever the subject
of include directives, and only .c files ever contain code.
(naturally, C doesn't enforce this, tools not rules, y'know,
but it sure makes the code easier to read.)
[And plenty of exceptions can be found, but let's not bombard
neophytes with the ugly real world just yet.]

Most imcrimental compiler schemes (and probably Think C, too) expect this
convention, and thus could be expected to be
confused if you #includ'ed a .c file.

Regards
Peter Miller










Path: ucivax!gateway
From: [e-mail] (Jan-Erik M}ngs)
Subject: Again: TCL 1.1.1, problems with scrollbars in subpanes...
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 45
Date: 3 Jan 92 14:03:58 GMT

Since I got no replies on my earlier posting, I'll try again:

There seems to be a problem with panoramas that contains
scrollbars within subpanes. To see the problem, look (for
example) at NewClassDemo. Change the windowType of DLOG ID 1030
("String demo") to documentProc or zoomDocProc. Run NewClassDemo
and select "String table demo..." from the Dialogs-menu. The
dialog will now have scrollbars. Make the dialog window smaller
so that only a part of the vertical scrollbar (for the list) is
seen. Now scroll using the "main" vertical scroll bar
(inDownButton) and see how the scrollbar belonging to the list
updates.

On a color monitor (256 colors) you can easily see that the
scrollbar belonging to the list is not drawn properly, it is
drawn on top of the main scrollbar. This happens in
CControl::Offset when the scrollbar is moved with MoveControl. I
have not had the time to track down the problem any further.

On a monochrome screen, the scrollbar only _sometimes_ look
wrong. But if you change hStep and vStep in CScrollPane and do
the same test, you will definitely see the problem. To do this,
comment out the line [marked (**)] in CDialog::MakePanorama
below (without this line, hStep and vStep will have their
default values):
.
.
if (fHasHScroll || fHasVScroll || fHasSizeBox) {
    scrollPane = new( CScrollPane);
    scrollPane->IScrollPane( this, this, 0, 0, 0, 0, sizELASTIC, sizELASTIC,
                    fHasHScroll, fHasVScroll, fHasSizeBox);
    scrollPane->FitToEnclFrame( TRUE, TRUE);
//(**)    scrollPane->SetSteps( kScrollSteps, kScrollSteps);
    scrollPane->SetID( kDialogScrollPaneID);

Has anyone else seen this problem and can confirm it? Any
workarounds? I'd like to have my windows set up like this. By
the way, TCL 1.1 for Pascal also have the same problem.

Another thing, any news on the problems with exception handling
and register allocation? That problem was not fixed in 1.1.1.

Thanks

    Kire










Path: ucivax!gateway
From: [e-mail] (Wade Williams)
Subject: Thanks...
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 14
Date: 3 Jan 92 14:07:38 GMT
X-Envelope-to: [e-mail]

Many thanks to those who responded to my question about THINK C build
order.

I was pretty proficient in Pascal, but I'm quickly learning what you
already know - C is a completely different creature.

-------------------------------------------------------------------------
Wade Williams                             "Any escape might help to smooth the
User Services Specialist            unattractive truth, but the suburbs
Academic Computing                     have no charms to soothe the restless
Auburn University                      dreams of youth." (N. Peart)
[e-mail]
-------------------------------------------------------------------------











Path: ucivax!gateway
From: cmiller@laurel (Craig Miller)
Subject: Re:  Are direct classes useful ?
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 37
Date: 3 Jan 92 16:53:58 GMT

Eric W. Sink ([e-mail]) writes:

> I want to create a special hierarchy of classes for my application.
> Objects for this set of classes will always be allocated in a
> special region of memory, for efficiency, and the classes therefore
> need to be direct.  Object references will be pointers to some
> portion of some locked pool of memory.
>
> Then I found out that subclasses cannot change the access specifier.
> Therefore, my hierarchy cannot be subclassed from CObject.
Therefore,
> I cannot store objects from my hierarchy in CLists or CStacks.
>
> It would appear to me that if I want a hierarchy of direct classes,
> I must then write my own hierarchy of Collection classes to support
> the new objects.

As far as I can tell your assertion is correct.  The Think C object
extensions are just not flexible enough to have a parent class be
indirect and the child class be direct.  Think about what would
happen if the parent class accesses its instance variable indirectly
and the child class accesses the same instance variable directly.
Code which uses the class may call methods which access the variable
directly, or other methods which access the same variable indirectly.
The compiled code for from one file or the other would have to be
incorrect.

You could recompile the TCL as direct objects only if there were no
assumptions about objects being implemented as handles.  This is
probably not the case.

-----------------------------------------------------------------------
Craig D. Miller, Computer Programmer          \  [e-mail]
Scientific Reasoning Research Institute (SRRI) \      tel. [phone]
306 Hasbrouck Lab                               \
University of Massachusetts, Amherst, MA  01003  \                  USA
-----------------------------------------------------------------------










Path: ucivax!gateway
From: [e-mail] (Wade Williams)
Subject: Global #defines
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 21
Date: 3 Jan 92 20:27:48 GMT
X-Envelope-to: [e-mail]

Ok, sorry for these simplistic questions, but I've got one more:

Is it possible to have a global #define such as:

#define    NIL                    (Ptr)0L
#define    MOVE_TO_FRONT        (WindowPtr)-1L



Using the scenario presented in my previous post, where would it go, in
Globals.c or Globals.h?

Thanks.
-------------------------------------------------------------------------
Wade Williams                             "Any escape might help to smooth the
User Services Specialist            unattractive truth, but the suburbs
Academic Computing                     have no charms to soothe the restless
Auburn University                      dreams of youth." (N. Peart)
[e-mail]
-------------------------------------------------------------------------











Path: ucivax!gateway
From: [e-mail] (Charles Mead)
Subject: Initialization of arrays
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 16
Date: 3 Jan 92 20:53:33 GMT


I'm sure I must be doing something trivially wrong, but I seem to have encountered a bug in the way that Think C initializes arrays.  Specifically, if the
array has only 2 elements in it (arrays in question are of type 'char') and
if the array is initialized at declaration (e.g. char word6[] = { 'a', 't', '\0'} and if the array is initialized as part of the initialization of several
similar arrays (i.e. suppose 3 arrays of type char are all declared and
initialized in one piece of code), THink C seems to be unable to correctly
insert the termination character for the 2-character-length array.

Has anybody heard of this bug or should I figure that I'm really missing
something obvious.  I have stepped through in the debugger and the incorrect
action definitely occurs at declaration, i.e. the array isn't begin written
over at some later point in the program.  I am running 4.0

Thanks for the help.

charlie mead










Path: ucivax!gateway
From: [e-mail] (Wade Williams)
Subject: #$! Prototypes!
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 43
Date: 4 Jan 92 01:24:26 GMT
X-Envelope-to: [e-mail]

Ok, last question (you don't believe that do you?):

If I have my function protyped as:

void DoMenu(EventRecord *gtheEvent);

called as:

DoMenu(>heEvent);

and declared as:

void DoMenu(EventRecord *gtheEvent)
{
some code...
}

with the variable declared as:

EventRecord gtheEvent;

why do I get a "argument to function does not match prototype" error?  The
way I see it, I'm passing it a pointer to an event record, and I specify in
the prototype that it will be receiving a pointer to an event record.  I
have turned off strict prototype enforcement, but it doesn't help.

I understood why I had to call get new window with:

GetNewWindow(128, NIL, (WindowPtr)-1);

But I don't see what I'm doing wrong on this one.

Again, I apologize for my ignorance..I just don't have any Mac C
programmers around here.

-------------------------------------------------------------------------
Wade Williams                             "Any escape might help to smooth the
User Services Specialist            unattractive truth, but the suburbs
Academic Computing                     have no charms to soothe the restless
Auburn University                      dreams of youth." (N. Peart)
[e-mail]
-------------------------------------------------------------------------











Path: ucivax!gateway
From: [e-mail] (Phil Shapiro)
Subject: Initialization of arrays
Message-ID: <[e-mail]>
In-Reply-To: Charles Mead's message of 3 Jan 92 20:53:33 GMT <[e-mail]>
Newsgroups: fa.think-c
Lines: 35
Date: 4 Jan 92 01:39:27 GMT

>> On 3 Jan 92 20:53:33 GMT, Charles Mead <[e-mail]> said:

 > I'm sure I must be doing something trivially wrong, but I seem to
 > have encountered a bug in the way that Think C initializes arrays.
 > Specifically, if the array has only 2 elements in it (arrays in
 > question are of type 'char') and if the array is initialized at
 > declaration (e.g. char word6[] = { 'a', 't', '\0'} and if the array
 > is initialized as part of the initialization of several similar
 > arrays, Think C seems to be unable to correctly insert the
 > termination character for the 2-character-length array.

This is correct; there is a bug in THINK C 4.0.x in the code that's
generated to initialize stack-based (auto) character arrays. The code
that THINK C 4.0 produces assumes that the array is placed at an
even-word boundry, and that it's of even length. This is sometimes not
the case, and incorrect code is produced.

To work around this problem in C 4.0, either:

- always use pointers instead of arrays
    char *word6 = "at";

- declare your arrays static
    static char word6[] = "at";

- initialize the array yourself, using a function call
    char word6[3]; strcpy(word6, "at");

This bug is fixed in THINK C 5.0.

    -phil
----
   Phil Shapiro                           Technical Support Analyst
   Language Products Group                     Symantec Corporation
        Internet: [e-mail]










Path: ucivax!gateway
From: [e-mail] (Blake Fordham)
Subject: color off-screen graphics
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 1
Date: 4 Jan 92 05:02:21 GMT

myAsk










Path: ucivax!gateway
From: [e-mail] (Bill Dugan)
Subject: (none)
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 1
Date: 4 Jan 92 09:48:30 GMT

unsubscribe










Path: ucivax!gateway
From: [e-mail] (Blake Fordham)
Subject: off-screen graphics
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 20
Date: 4 Jan 92 19:47:04 GMT

Sorry about the last message, I missed typed and didn't catch it until too
late.  Anyway, here's my question:

  I'm still working on setting up an off-screen graphic, but I recently
got my update to C 5.0, so I thought I would try to use TCL.  So far, I'm
happy with the results, but I've run into a problem.  I have a 2D array of
short ints that correspond to PICTs in the res file;  I want to display
the PICT (all are the same size) in a tiled arrangement reflecting the
array.  I can do it with CBitMap and CBitMapPane objects, and it looks
great and update invisibly, but I need to display the picts in color not
BW.  I want to be able to chnge the array in response to the user and have
the PICTs change accordingly.  Do I need to build a GWorld version of CBitMap
or is there an easier solution?  I thought about attaching an array of CPicture
objects to the document object, but will this react quickly enough, and how
do I set the itsGopher instance in MyDoc::BuildWindow()?  I want the window
to beable to detect mouse events in the individual picts.  Anyone have any
idea of what is the best solution?  I'd appreciate any input.

Blake Fordham
blake.seagull.math.byu.edu










Path: ucivax!gateway
From: [e-mail] (Gadi Eidelheit)
Subject: (none)
Message-ID: <[e-mail]>
Comments: Internet address: bimacs.cs.biu.ac.il. Bitnet address: bimacs.bitnet.
     Old internet address (bimacs.biu.ac.il) is available only temporarily.
Newsgroups: fa.think-c
Lines: 2
Date: 5 Jan 92 07:46:15 GMT

Please add me to the mailing list...
thanks Gadi Eidelheit










Path: ucivax!gateway
From: [e-mail] (Peter Kay)
Subject: How difficult is my problem?
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 64
Date: 6 Jan 92 09:35:09 GMT


Although I have been scanning this list for some time, this is my first
request for information. I hope that you will make allowances if the
question is very stupid. I am fairly new at C programming and even more
of a beginner in programming for the Mac environment.  I have been
wrestling with a particular problem for some time.

I am doing a research project which involves the use of the Voice
Navigator (VN) speech recogniser on a Mac IIcx and using System 7.0.
The VN software includes facilities for the creation of "language
files" which allows one to use existing applications with speech-only
input, e.g. MacDraw II.

One of the difficulties with the VN software is that the slowest
speech-controlled cursor movement is too fast for my purposes.  My
calculations are (by timing cursor movement accross a 19" screen) that
the rate of cursor movement is 1 pixel per tick.  The VN software
allows one to write Voice Extensions (VXTN) in C, Pascal, or assembly
language. Since I have Think C 5.0.1, I would like to attempt to write
a VXTN which would slow down the cursor to 1/10th (say) of the above
speed.

The  main VN software is in the form of a driver and all text input
(created by speech input) is entered into a queue by the recognition
portion of the driver, then independently pulled off the queue either
at GetNextEvent time or during driver runtime. The VN manual states
that "when writing a VXTN, you cannot be assured that the operating
system will still be in the same state as when you queued the output
string. Your application may no longer be the front application; the
stack and A5 could be different.  Therefore, your VXTN will have to set
up any globals it needs, and if the executed actions involve callbacks
to your application, the VXTN should check to see if your application
is actually running."  Apparently, there is no problem with VXTN making
calls that move memory since the driver does all of its processing at
well defined times. Also, the driver is re-entrant, so that the VXTN
can make immediate calls back to the driver and can even put up a modal
dialogue to interact with the user.  The manual also gives details of a
VoiceControl header file in terms of specific definitions and
structures (in C).

My main question is this:-

Would I be tackling something that is well and truly above my
head or can the problem be solved by a relatively trivial piece of
code? .... or is it somewhere in between?

If not "over my head", I would be very grateful for any pointers in the
right direction. For example, what are the primary toolbox routines
with which I should be concerned?  Also, am I correct in thinking that
the functions connected with the movement of the cursor are completely
independent of whether the (speech controlled) mouse button is down or
up?

I have access to Inside Macintosh (I - V), Macintosh Revealed, Mark's
Macintosh Programming Primers (I - II) and, of course, Think C manuals.

I have put in many, many hours of trying to solve this problem (even by
very indirect methods) before resorting to this PLEA FOR HELP!


Peter Kay,  Division of Computer Science,   Hatfield Polytechnic
Hatfield, Herts, U.K.   AL10 9AB  ---------  tel.no. 07072 79358
INTERNET(USA):   [e-mail]
JANET: [e-mail]  BITNET/EARN: comqpk%hatfield.ac.uk@ukacrl










Path: ucivax!gateway
From: [e-mail] (Nick Rothwell)
Subject: Bug in TC5.0.1 Compiler....
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 9
Date: 6 Jan 92 15:40:38 GMT

...i.e. in the application's operation itself rather than what it does.
TC5.0.1 disables QUIT when it's running something - this makes sense - but
can still be closed down from the Finder. Nothing bad seems to happen
unless the project is running under the debugger. Then, if the Finder
shutdown procedure happens to close down the compiler before the project,
the project and debugger are still there, and anarchy ensues.

        Nick.











Path: ucivax!gateway
From: [e-mail]
Subject: ARCHIVE: THINK Back 1.0 Extension
Message-ID: <[e-mail]>
In-Reply-To: Mark Nagel's message of 26 Dec 91 15:58:00 GMT <[e-mail]>
Newsgroups: fa.think-c
Lines: 9
Date: 6 Jan 92 15:40:46 GMT

>but I'm sure that some bugs still
>remain; please email any to me.

The only thing I've noticed is that it occasionally hangs when it's finished
with a source file and I've been flipping around between applications. When
it hangs there's no clean recovery procedure, although an ExitToShell from
MacsBug seems fairly harmless to the project.

    Nick.










Path: ucivax!gateway
From: [e-mail] ("Mr. Neb")
Subject: ProcPtr parameters
Message-ID: <[e-mail]>
X-VMS-Cc: DNEBING
Newsgroups: fa.think-c
X-VMS-To: IN%"[e-mail]"
Lines: 15
Date: 6 Jan 92 22:11:38 GMT
X-Envelope-to: [e-mail]


    I want to know about ProcPtr parameters.  I understand that to pass
them to the toolbox one must define the procedure as a pascal function.
That much is easy.
    What I want to do is to pass a procedure to one of my own procedures,
more or less passing a filter function to a standard procedure.  As far as
passing the procedure, that is not a problem.  The problem comes when I try
to reference the procedure.  I have tried many different ways, but at most
think-c is telling me that I am making a call to a null function, or something
like that.
    Could someone clear up this problem that I have?  If so, I offer
thanks in advance.

    [e-mail]











Path: ucivax!gateway
From: [e-mail] ("Haseen I. Alam")
Subject: question regarding IUTimeString
Message-ID: <[e-mail]>
X-Mailer: ELM [version 2.3 PL11]
Newsgroups: fa.think-c
Lines: 41
Date: 7 Jan 92 04:25:41 GMT


 Hi again,

    First of all, many thanks to Thomas and Kirk Swenson for helping me with
    my previous set of questions.  It turns out, the menu ID's were not set
    properly in ResEdit 2.1, so I set them Using ResEdit 1.2 (don't ask me
    why).  It is interesting how you get 2.1 by swapping the digits in 1.2!!!
    (don't ask me this either).

    Anyway, now the menus are drawn and I can change the font and style from
    their sub menus and the change show up on my little window.  COOL!  But
    for some reason IUTimeString does not return a valid string.  So if I
    comment out the call to this routine and just print a constant string,
    then the Timer program in Mac Programming Primer Vol 1 works.  I used the
    debugger to print the value of myTimeString after the call to
    IUTimeString and it prints ???.  The vars are defines as follows, the
    first two are globals and the third is local to DrawClock, which contains
    the call to IUTimeString.

        #define     INCLUDE_SECONDS        TRUE
        long int    gCurrentTime ;
        Str255        myTimeString ;

    First, gCurrentTime is set by a call to GetDateTime, then IUTimeString is
    called to "get the current time in a format suitable for display."  The
    calls to these two routines are as follows:

        GetDateTime (&gCurrentTime) ;
        IUTimeString (gCurrentTime, INCLUDE_SECONDS, myTimeString ) ;

    But the value that I get back from IUTimeString is garbage (I don't know
    why).  Yes, I guess I should get IM, but kinda short of money at this time.
    So I ordered THINK Reference, which is supposed to be an electronic version
    of IM 1-5 (kinda!).  But till then if someone could help me solve this
    mystery I would really appreciate the favour.  Thanks in advance.

 Haseen.
 .-------------------------------------------------------------------------.
 | "If you think I am expensive, wait  | email: [e-mail]        |
 |     till you hire an amateur!"      |    or  [e-mail] |
 `-------------------------------------------------------------------------'










Path: ucivax!gateway
From: [e-mail] (Phil Shapiro)
Subject: ARCHIVE: THINK Back 1.0 Extension
Message-ID: <[e-mail]>
In-Reply-To: [e-mail]'s message of 6 Jan 92 15:40:46 GMT <[e-mail]>
Newsgroups: fa.think-c
Lines: 31
Date: 7 Jan 92 12:46:31 GMT

Hi Nick,

>>>>> On 6 Jan 92 15:40:46 GMT, [e-mail] said:

 > The only thing I've noticed is that it occasionally hangs when it's
 > finished with a source file and I've been flipping around between
 > applications. When it hangs there's no clean recovery procedure,
 > although an ExitToShell from MacsBug seems fairly harmless to the
 > project.

The problem seems to be this: if you start a compile, put it into the
background, obscure the project window in some way, then bring think c
in the foreground by clicking on the project window, *and* the
obscured part of the project window hasn't yet been redrawn, then an
infinite loop occurs. I think that my patch code is missing a resume
event from the toolbox, so it's ignoring events that should be passed
on to THINK C. (This is definitely the problem.)

The problem doesn't seem to happen when I don't have CMaster
installed; it's possible that our GNE hooks are interfering in some
way.

Due to the way that the THINK C project update works, your projects
should never get corrupted by doing an ES in MacsBug at this point (at
least I've never had a problem...).

    -phil
----
   Phil Shapiro                           Technical Support Analyst
   Language Products Group                     Symantec Corporation
        Internet: [e-mail]










Path: ucivax!gateway
From: [e-mail] (Mark Gross)
Subject: Please remove this user
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 12
Date: 7 Jan 92 14:40:47 GMT



    Could you please remove this user from your mailing list.  He has left
    our company and no longer has access to his email.


    Darin S. Lory
    System Administrator
    Kaman Sciences Corporation
    Utica, New York
    <[e-mail]>  or  <[e-mail]>











Path: ucivax!gateway
From: [e-mail] (Wade Williams)
Subject: Window or Dialog?
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 23
Date: 7 Jan 92 19:56:57 GMT
X-Envelope-to: [e-mail]

Several places I've seen recommendations that the dialog manager only be
used for user input.  That is to say, it should not be used for major tasks
and the Window manager should be used for such.

I want to implement a message window that has several static text fields, a
few buttons and of course, an edit text field for entering the message.
Naturally, the Dialog manager *seems* to be the natural way (and easiest)
to do this, but again, some advise that it was never intended for that type
of task.

No message will be over 32K, so I'll just be using TextEdit.  What do you
think?  Would the Dialog manager be sufficient, or should I use the Window
Manager even though it means writing much of the code for button and field
maintenance myself?

-------------------------------------------------------------------------
Wade Williams                             "Any escape might help to smooth the
User Services Specialist            unattractive truth, but the suburbs
Academic Computing                     have no charms to soothe the restless
Auburn University                      dreams of youth." (N. Peart)
[e-mail]
-------------------------------------------------------------------------











Path: ucivax!gateway
From: [e-mail]
Subject: MacIntalk query
Message-ID: <920107170158995-MTASATURN*[e-mail]>
P1-Message-ID: US*UMASSMAIL*UMASS; 920107170158995-MTASATURN
X400-Trace: US*UMASSMAIL*UMASS; arrival Tue, 7 Jan 92 17:07:07 -0500 action
 Relayed
Newsgroups: fa.think-c
UA-Content-ID: 920107170158995-
Lines: 10
Date: 7 Jan 92 22:08:27 GMT

Hello,
I'm interested in speech syntesis using MacIntalk (I'm interested in any
program/code that does speech synthesis on the Mac using text). I have the
program, some stacks that use it, and some code that uses it, but in all cases
there is no real info about the program. I would like to know if anyone knows
where I can find info on MacIntalk and even info on speech generation on the
Mac, so I can use it and abuse it.
I thank you in advance,
Charlie Schick
[e-mail]










Path: ucivax!gateway
From: [e-mail] (Sigurdur Darri Skulason)
Subject: vt102-emulator / comm toolbox
Message-ID: <[e-mail]>
X-Mailer: ELM [version 2.3 PL11]
Newsgroups: fa.think-c
X-Charset: ASCII
Lines: 23
Date: 8 Jan 92 01:01:22 GMT
X-Char-Esc: 29


  Thanks to those who answered my enquery about a tcp tool for the
Macintosh Communication Toolbox. Apparently, there is no such tool as of now.
Therefore the choice now stands between writing one on our own or
just abort the ctb and write the mactcp interface routines ourselves and
I suppose that is what we will do.  However, one of the main reasons for
choosing the ctb was the availability of a vt102 emulator in it.
 If we will skip the ctb, then we will therefore need to write some vt-102
 emulating code, which wouldn't be a problem if I could only find some
information about that standard. That has however proved itself to be
strangely difficult, considering the widespread use of that standard.
Therefore, if you do have a table of the control codes or some sample
code, then I would really appreciate it, if you could email it to me.

   Thanks in advance,
          -sidar.

------------------------------------------------------------
Sigurdur Darri Skulason                   [e-mail]
President, Hugsun inc.
Tecnhological Park
Dunhagi 5, IS-107 Reykjavik, Iceland











Path: ucivax!gateway
From: [e-mail] (Pete Resnick)
Subject: Re: vt102-emulator / comm toolbox
Message-ID: <[e-mail]>
X-Mailer: Eudora [version 1.3a11 CTB]
Newsgroups: fa.think-c
Lines: 17
Date: 11 Jan 92 05:09:52 GMT

I must have missed your original posting.

>  Thanks to those who answered my enquery about a tcp tool for the
>Macintosh Communication Toolbox. Apparently, there is no such tool as of now.

There is a TCP/IP tool available from Advanced Software Concepts, a french
company. I know that Pacer has licensed it for PacerTerm.

I would stick to the CTB if at all possible.

pr
--
Pete Resnick        (...so what is a mojo, and why would one be rising?)
Graduate assistant - Philosophy Department, Gregory Hall, UIUC
System manager - Cognitive Science Group, Beckman Institute, UIUC
Internet: [e-mail]











Path: ucivax!gateway
From: [e-mail] ("(Michael A. Kelly)" )
Subject: When should I avoid breaking into the Think Debugger?
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 34
Date: 13 Jan 92 02:08:33 GMT




Are there any points in a typical Mac application when I should avoid
breaking into the Think Debugger?  Suppose, for instance, that the program
is in the process of displaying a modal dialog, and I break into the Think
Debugger and step through the code.  Could there be any side effects from
doing this that could affect other programs, or the system?


The debugger in question is the Think C Debugger 5.0.1.


I ask, of course, because I've been having problems.  I usually have to
restart after a session with the debugger because the debugger seems to
release a virus into the system as it quits.  Everything's fine until I
quit the application/debugger and then I usually have just enough time to
quit all the running applications and restart before the machine crashes.
Pretty frustrating.


So, anyone have any ideas?


Thanks,


Mike.
_____________________________________________________________________________
Michael A. Kelly                                         University of Oregon
[e-mail]                             Computer Science Department
_____________________________________________________________________________
"Never test for a bug you don't know how to fix."
        - anonymous










Path: ucivax!gateway
From: [e-mail] (David Sugar)
Subject: SFFile Structure
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 27
Date: 13 Jan 92 03:58:23 GMT


  Ok, this is probabily a fairly simple question so I expect some responces..
Anyway, I'm working on a background only appe ("Drag and Drop" thing) that
will convert a PICT file into a PICT resource.  My first question is how
can I build a SFFile rec for when I open a resource file to stick my output
file into.  Since it's a background only appe there won't be any interface
and so I won't be asking the user for a file name to output into.  Is there
a simple way to manualy build this record to the same path that the appe
is in.  So the output file will be in the same folder as the appe that
created it.

  Ok, also while I'm mail you all, where do I get the name of the file that
is actually dropped onto the appe??  Like when a user dropps some PICT file
on my appe where does the appe get the file name and path of the that file?
do you use something like   main(argc,argv)  ??  or is there something
special to use??

  And finally, I'm planning on using the WritePartialResource call so I don't
have to read in the entire PICT into memory and then put it in the resource.
Is there anything tricky that I should be aware of when I start getting into
that part??

Thaks,

Dave Sugar
[e-mail]











Path: ucivax!gateway
From: [e-mail]
Subject: Re: SFFile Structure
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 21
Date: 13 Jan 92 14:29:29 GMT

--- David Sugar wrote:
Anyway, I'm working on a background only appe ("Drag and Drop" thing) that
will convert a PICT file into a PICT resource.
--- end of quoted material ---

Apparently there's no such thing as a drag-and-drop 'appe'; 'appe' files are
only launched at startup.  The Apple line is that applications that accept
dragged files can not be "faceless".  So you should put together a minimal
user interface (such as a progress window that tells the user what's going on,
and lets the user switch to another application).  You get the names of the
"input" files by handling the 'ODOC' AppleEvent (see the AppleEvent chapter of
IM VI) under system 7 and using GetAppFile() for compatibility with earlier
systems (see the Segment Loader chapter of IM II).

You can get a reference to the working directory that your app is in by
calling GetVol() before any calls to SetVol().

Hope this helps,

Jim Matthews
Dartmouth Software Development










Path: ucivax!gateway
From: [e-mail] (Craig Hollabaugh)
Subject: Re:  When should I avoid breaking into the Think Debugger?
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 11
Date: 13 Jan 92 16:50:55 GMT

>> Are there any points in a typical Mac application when I should avoid
>> breaking into the Think Debugger?

Here is a debugging tip: Don't single step across Event functions. I found
that AcceptHighLevelEvent doesn't return appropriate values if you stop
before it and step across. Other Event functions probably behave similiarly.
So my tip is put your stops after Event functions.

Craig Hollabaugh
Analog Microelectronics, Georgia Tech
[e-mail]










Path: ucivax!gateway
From: [e-mail] (John J Chew)
Subject: Re:  When should I avoid breaking into the Think Debugger?
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 17
Date: 13 Jan 92 17:30:34 GMT

In message <[e-mail]>, Michael A. Kelly
  <[e-mail]> writes:

> Are there any points in a typical Mac application when I should avoid
> breaking into the Think Debugger?

I found that using Debugger() in a MacTCP ASR or callback is dangerous when
debugging an application using the Think Debugger, but I probably should have
known better.

John
--
John J. Chew, III                            * [e-mail]
AIS/Berger-Levrault * phone [phone]  * [e-mail]
18, rue des Glacis  * fax   [phone]  * [e-mail]
F-54017 Nancy Cedex * telex BL NANCY 960 212 * [e-mail]
"TCP _a_synchronous _n_otification _r_outine (_A_S_R_)"










Path: ucivax!gateway
From: [e-mail] (John J Chew)
Subject: VT-102 emulation
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 43
Date: 13 Jan 92 17:45:07 GMT

In response to ... (bother... rummage, rummage... er...) someone from .is
who asked whether or not VT-102 specifications and/or a THINK C class are
available if he didn't want to use CTB:

I am working on a THINK C VT-220 emulator pane, and while it is by no means
complete, if you are in a fix I could send you a copy in library form that
you could alpha-test.

(The VT-220 command set is a superset of the VT-102 set and can be restricted
to run in strict VT-100 compliant mode, the VT-100 set being a subset of the
VT-102.)

By the end of today the pane should support:

- 80-/132-column operation (except you need 527 horizontal pixels to see
  132 columns at 6 point, or 791 at 9 point)
- ASCII, VT-100 graphic and ISO character sets
- bold, reverse video and underlined characters
- copy + paste (with both TEXT and styl generated on copy)
- most controls and escape sequences, certainly enough to use curses.
- playing of named sound resources using a special escape sequence

It does not yet support:

- blinking characters
- downloadable character sets
- extra-wide, extra-tall etc. characters
- insert/delete character/line sequences (RSN)
- keyboard input mapping (for function keys or eight-bit characters)
- national character sets
- VT-52 emulation

The class is a little less than 11K and is a descendant of CPane with new
methods Read() and Write() to read keyboard input and write to the terminal
emulator.

John
--
John J. Chew, III                            * [e-mail]
AIS/Berger-Levrault * phone [phone]  * [e-mail]
18, rue des Glacis  * fax   [phone]  * [e-mail]
F-54017 Nancy Cedex * telex BL NANCY 960 212 * [e-mail]
"Les arbres sont souvent en cause dans les accidents de la circulation."










Path: ucivax!gateway
From: [e-mail] ("Povl H. Pedersen")
Subject: Re: SFFile Structure
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
X-Vms-To: IN::"[e-mail]"
Lines: 8
Date: 13 Jan 92 17:49:42 GMT
X-Envelope-To: [e-mail]


I see no reason why to make an 'appe'. Just make it an APPL, and
then set the background only flag. Then put it into the startup items
folder, and it will do what you want. Then suspend itself when done.
Finder will reopen it when needed for new docs.

Povl H. Pedersen
[e-mail]










Path: ucivax!gateway
From: [e-mail] ("Mr. Neb")
Subject: Re: Bug in TC5.0.1 Compiler....
Message-ID: <[e-mail]>
X-VMS-Cc: DNEBING
Newsgroups: fa.think-c
X-VMS-To: IN%"[e-mail]"
Lines: 5
Date: 13 Jan 92 20:29:57 GMT
X-Envelope-to: [e-mail]


    What is bad about disabling the quit menu option is when your
little program gets stuck in some kind of bug-induced loop for which you
can not escape....











Path: ucivax!gateway
From: [e-mail] ("Mr. Neb")
Subject: ProcPtr parameters v2
Message-ID: <[e-mail]>
X-VMS-Cc: DNEBING
Newsgroups: fa.think-c
X-VMS-To: IN%"[e-mail]"
Lines: 37
Date: 13 Jan 92 20:44:37 GMT
X-Envelope-to: [e-mail]


    This is the type of thing that I want to implement:

void foo(ProcPtr BarProc){
    int a;

    ...
    a=BarProc();
    ...
}

int BarOne(void){
    ...
}

int BarTwo(void){
    ...
}

main(){
    foo(BarOne);
    foo(BarTwo);
    ...
}

    This is just a small example.  Taken apart, I have one function
which should accept another function as a parameter.  To pass a function
to one of the toolbox calls (i.e. a filter procedure) it must be declared
as:
    pascal short myfilter();
before it can be passed as a parameter.  What is the syntax to pass BarOne
or BarTwo to one of my own procedures.  I get wacked out error messages when
I try to do it like the example above.

    Any answers?

    [e-mail]










Path: ucivax!gateway
From: [e-mail] (Taylor Leaming 801/582-5847 x3836)
Subject: Think C Project segmentation and #pragma segment directive
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 31
Date: 13 Jan 92 22:19:34 GMT
X-Vmsmail-To: SMTP%"[e-mail]"

I have a question concerning how Think C's project file and the C preprocessor
#pragma segment directive (from MPW) can be used together to segment your
source files and function routines.

Want I'm after is to be able to put functions into files where they make sense
logically, grouping them by their relationships to each other.

Then, I want to be able to use #pragma segment directive to group them.

From what I've been able to find, Think C provides for only four #pragma
directives, the segment directive not being one of them.  However, the Project
file lets you organize FILES into segments.

So you can group you functions into files so they can be placed into separate
segments in the Think C project, or live with it.

What are people doing to overcome this problem?

I would like to be able to port in files from MPW which allows for the
#pragma segment directive, and retain the best virtues of both worlds.

Thanks in advance,

Taylor

--------------------------------------------------------------------------
Taylor Leaming                                  [e-mail]
Simulation Division
Evans & Sutherland Computer Corp.
SLC, UT                                                       801/582-5847











Path: ucivax!gateway
From: [e-mail] (The Spanish Inquisition)
Subject: Plenty Questions
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 31
Date: 14 Jan 92 17:34:28 GMT

Using the Mac Primer, I have successfully cleared the screen (mimicking the
flying line demo), but I can't find the command to plot a single point on the
screen, so

Do pixels reside in a specific area of memory?  If so, what hexidecimal range
would it be or how could I find out?

What command could I use (with coordinates now, not hex) to plot a point?
Basic has its PSET, etc.

Are there any references/sample programs that I could access to find out more
about graphics?  Specific programs on info-mac, a book such as the Mac Primer,
any information would be greatly appreciated.

Thanks in advance!

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

  _______________                                      /
 ///==========///                                     /   Eric Lawson
///          ///                                     /
            ///               _____________         /   [e-mail]
       ____///_________      ///==========/        /   [e-mail]
      /=============///    ///                    /
         ///        ///  ///                     /   P.O. Box 240652
        ///         //////                      /   Douglas, AK 99824
       ///          ////                       /   [phone]
      ///           //                        /
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=












Path: ucivax!gateway
From: [e-mail] (Pete Resnick)
Subject: SetUpA4 and optimizations - solution
Message-ID: <[e-mail]>
X-Mailer: Eudora [version 1.3a11 CTB]
Newsgroups: fa.think-c
Lines: 49
Date: 15 Jan 92 01:18:37 GMT

As you all probably have noticed, THINK C 5.0 will do no optimizing if
there is any inline assembler in a function. This is especially sad if you
use the SetUpA4.h libraries, since they are written in inline assembler. I
have re-written SetUpA4.h to use inline function calls, which THINK C will
optimize around, though it still does generate some silly code:

+0004  000322  MOVEM.L    D4-D7/A2/A3,-(A7)                        | 48E7
0F30
+0008  000326  MOVE.L     A4,-(A7)                                 | 2F0C
.
.
+00B4  0003D2  MOVEA.L    (A7)+,A4                                 | 285F
+00B6  0003D4  MOVEM.L    (A7)+,D4-D7/A2/A3                        | 4CDF
0CF0

But the rest of the code generated is loads better. If anyone sees any
problems with the following, please let me know.

pr
--
Pete Resnick        (...so what is a mojo, and why would one be rising?)
Graduate assistant - Philosophy Department, Gregory Hall, UIUC
System manager - Cognitive Science Group, Beckman Institute, UIUC
Internet: [e-mail]

/* MySetUpA4.h -- Pete Resnick, January 1992 */

static void
__GetA4(void)
{
    asm {
        bsr.s    @1
        dc.l    0            ;  store A4 here
@1        move.l    (sp)+,a1
    }
}

static void __StoreA4(void) = {0x228C};
static void __StoreA0(void) = {0x2288};
static void __PushA4(void) = {0x2F0C};
static void __RetrieveA4(void) = {0x2851};
static void __PopA4(void) = {0x285F};

#define RememberA4()    do { __GetA4(); __StoreA4(); } while (0)
#define RememberA0()    do { __GetA4(); __StoreA0(); } while (0)

#define SetUpA4()        do { __PushA4(); __GetA4(); __RetrieveA4(); } while (0)
#define RestoreA4()        do { __PopA4(); } while (0)











Path: ucivax!gateway
From: [e-mail] (Pete Resnick)
Subject: SetUpA4 and optimizations - solution
Message-ID: <[e-mail]>
X-Mailer: Eudora [version 1.3a11 CTB]
Newsgroups: fa.think-c
Lines: 55
Date: 15 Jan 92 05:21:10 GMT

Sorry for the re-post. Evidently the last one got cut off.

As you all probably have noticed, THINK C 5.0 will do no optimizing if
there is any inline assembler in a function. This is especially sad if you
use the SetUpA4.h libraries, since they are written in inline assembler. I
have re-written SetUpA4.h to use inline function calls, which THINK C will
optimize around, though it still does generate some silly code:

+0004  000322  MOVEM.L    D4-D7/A2/A3,-(A7)                        | 48E7
0F30
+0008  000326  MOVE.L     A4,-(A7)                                 | 2F0C
...
+00B4  0003D2  MOVEA.L    (A7)+,A4                                 | 285F
+00B6  0003D4  MOVEM.L    (A7)+,D4-D7/A2/A3                        | 4CDF
0CF0

But the rest of the code generated is loads better. If anyone sees any
problems with the following, please let me know.

pr
--
Pete Resnick        (...so what is a mojo, and why would one be rising?)
Graduate assistant - Philosophy Department, Gregory Hall, UIUC
System manager - Cognitive Science Group, Beckman Institute, UIUC
Internet: [e-mail]

/* MySetUpA4.h -- Pete Resnick, January 1992 */

static void
__GetA4(void)
{
    asm {
        bsr.s    @1
        dc.l    0            ;  store A4 here
@1        move.l    (sp)+,a1
    }
}

static void __StoreA4(void) = {0x228C};
static void __StoreA0(void) = {0x2288};
static void __PushA4(void) = {0x2F0C};
static void __RetrieveA4(void) = {0x2851};
static void __PopA4(void) = {0x285F};

#define RememberA4()    do { __GetA4(); __StoreA4(); } while (0)
#define RememberA0()    do { __GetA4(); __StoreA0(); } while (0)

#define SetUpA4()        do { __PushA4(); __GetA4(); __RetrieveA4(); } while (0)
#define RestoreA4()        do { __PopA4(); } while (0)
--
Pete Resnick        (...so what is a mojo, and why would one be rising?)
Graduate assistant - Philosophy Department, Gregory Hall, UIUC
System manager - Cognitive Science Group, Beckman Institute, UIUC
Internet: [e-mail]











Path: ucivax!gateway
From: [e-mail] (Erik Warren Selberg)
Subject: Custom Dialog and TCL
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 24
Date: 15 Jan 92 05:31:43 GMT

(I sent this out a bit ago, but haven't had much luck with the
responses.  Anyway, here goes again:)

I'm trying to create a custom dialog / window which does the
following:

Has three lists
  (1) a list of PICTs
  (2) a standard list of function names
  (3) a list of timings (timing = a name + a bunch of squares)

What I want to do is:
  Select some PICTs, some functions, and some of the squares in the
timing (preferably, the name would not be highlightable), then signal
the program that the user has done this.  How would I go about doing
this using the TCL?

Thanks,
Erik


                          -/-   flup! flup! flup!   -\-
ARPA: [e-mail] -\- It's not just a name. -/- Fido: 129/107
Don't sue, I'm broke      -/-     It's a dance.     -\- BBS:  [phone]










Path: ucivax!gateway
From: [e-mail] (Daniel LaLiberte)
Subject: Templa Graphica
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 21
Date: 15 Jan 92 15:40:16 GMT

I just picked up the "Templa Graphica" book and disks from the bookstore.
It is a very interesting "Generic Graphical Editor" for the mac, similar
to Diagram! for the NeXT, but perhaps more powerful - I'm not sure yet.
What you do is define a notation template file for your domain of interest
with the Templa program, and then use it with the Graphica program.

Anyway, the source code is included and it is in THINK C.  Good thing too
since it was not possible to open a new document for a new template.
Otherwise it appeared to run fine under system 7 on a IIfx.  So I went
about recompiling the source using THINK C 5.0 and fixed a bunch of
missing cast problems (I couldn't get THINK C to ignore them).  The
actual bug was easy to fix.  I'm willing to share my fixes with anyone
who wants them.  But I'd also like to get ahold of the author, Dr Sharam
Hekmatpour of Advanced Imaging Systems Kodak (Australasia) Pty Ltd.


Dan LaLiberte
National Center for Supercomputing Applications

[e-mail]
(Join the League for Programming Freedom: [e-mail])










Path: ucivax!gateway
From: [e-mail] ("Eric W. Sink")
Subject: Re: Custom Dialog and TCL
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>; from "Erik Warren Selberg" at Jan 15, 92 5:31 am
X-Mailer: ELM [version 2.3 PL11]
Newsgroups: fa.think-c
Lines: 100
Date: 15 Jan 92 15:43:03 GMT

> I'm trying to create a custom dialog / window which does the
> following:
>
> Has three lists
>   (1) a list of PICTs
>   (2) a standard list of function names
>   (3) a list of timings (timing = a name + a bunch of squares)
>
> What I want to do is:
>   Select some PICTs, some functions, and some of the squares in the
> timing (preferably, the name would not be highlightable), then signal
> the program that the user has done this.  How would I go about doing
> this using the TCL?

Making dialogs is not the easiest thing in TCL.  Using the CDialog classes
seems the best way to go, but it is not well documented.  Here is the
way I am doing a dialog :

1.  I design the dialog as usual in ResEdit.  Assign command numbers to
    the buttons (Ok#100,Cancel#101).  Look at the comments at the end
    of CDLOGDialog.c for info on how to create special panes and stuff
    like that.  Keep in mind as you design the dialog that the result
    will be a collection of objects, not a normal Mac dialog.  The CDialog
    classes handle dialogs as plain windows with controls in them.  They
    do not use the Dialog Manager.

2.  Now, when you start up the dialog, TCL scans the DITL resource
    created by ResEdit, and creates a CDLOGDialog object corresponding to the
    Dialog you designed.  The problem is that you need access to the
    individual objects in dialog.  Basically you have to search the dialog
    using the item numbers as keys.  For example, suppose that item 5
    is a check box button :

  aCheckBox = (CCheckBox *) myDialogDirector->itsWindow->FindViewByID(5);

    Now, aCheckBox is a pointer to a CCheckBox object which you can
    manipulate as you please.  For example, you can set its current
    state according the some flag.  You can SetClickCmd on it, and
    then add code to a DoCommand method to handle it.  You can check
    its status after the dialog is closed.

    In general, this is how I get access to the individual items in
    a TCL dialog.

Now, all of the above does very little to answer your question since your
need is a special case.  There is no TCL class to represent a List Manager
list.  Now, I think I saw one in MacTutor once...  However, the CTable
class does a fine job of imitating a list, and is more versatile.  See
the NewClassDemo application for an example.

You have three options, as I see the situation :

1.  Code the lists using the List Manager like you would if this
    were standard C.  I don't know how you would do this exactly, but
    it certainly can be done.  I don't recommend it either.

2.  Find the MacTutor back issue and use that list class.

3.  Use the CTable class to simulate a list.

With either of options 2 or 3, one problem is that you will not be
able to place the list in the dialog using ResEdit.  To my knowledge,
CDLOGDialog does not know how to create CTable objects from a resource
specification.  You will therefore have to add the object to the
dialog by hand.  This basically involves creating the CTable object
and initializing it with correct coordinates and with the CDLOGDialog
as its parent, and with the CDLOGDirector as its supervisor (someone
correct me if this is wrong).

To "signal the program that the user has done this" you will want to use
the facilities provided by the CTable object, probably adding some
command number which you will have to handle in a DoCommand somewhere.
I can't provide details since I don't have the manuals here.

The dialog you want is a complex one.  You will no doubt find yourself
frustrated with TCL, saying something like, "I thought this thing
was supposed to make it *easier*".  A word of unsolicited advice :

All OO frameworks carry a steep learning curve.  It's hard to learn
to do anything with the framework right away.  Unlike Smalltalk,
all frameworks based on a derivative of C offer you a way out.
If you get real frustrated, you will be tempted to just code your
application without making use of the existing classes and OO facilities.
Try to resist this temptation.  The classes are there for your benefit,
and it will be well worth your effort in the long run to learn them.

It is unfortunate that latest classes in the TCL are poorly documented.
No doubt, proper documentation is forthcoming, but until then, our
predicament is very much that of a beginning Smalltalk programmer.  The
only real hope is find someone who knows what is going on.

I'm no TCL expert, so I hope that someone more experienced will correct
my mistakes and fill in the gaps.

Hope this helps,

--
Eric W. Sink,  Spatial Analysis and Systems Team
USACERL, P.O. Box 9005, Champaign, IL 61826-9005
1-800-USA-CERL x449,   [e-mail]










Path: ucivax!gateway
From: [e-mail] (Douglas Yarrington)
Subject: icons & ListManager
Message-ID: <[e-mail]>
X-Mailer: ELM [version 2.3 PL0]
Newsgroups: fa.think-c
Lines: 15
Date: 15 Jan 92 18:08:25 GMT

People,

Could someone give me some advice on the best way to implement a list
using the standard ListManager that will incorporate icons similar to
the standard file lists.

As a sub-issue, why hasn't the standard List Manager been updated to
accomodate such lists directly?

Thanks.

--douglas

_______________________________________________________________________________
 Douglas Yarrington                                 [e-mail]










Path: ucivax!gateway
From: [e-mail] (Daniel LaLiberte)
Subject: re: Templa Graphica info
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 8
Date: 15 Jan 92 19:09:12 GMT

A little more info on Templa Graphica.

"Templa Graphica: A Generic Graphical Editor for the Macintosh"
by Dr Sharam Hekmatpour, 1990 by Prentice Hall of Australia Pty Ltd
ISBN: 0-13-904160-5
$59.00 including two disks with software and THINK C source.

dan










Path: ucivax!gateway
From: [e-mail] (Blake Fordham)
Subject: scroll panes
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 13
Date: 16 Jan 92 16:32:47 GMT

I just started using TCL and I've run into a small idiosyncrasy that I
can't track down.  I have a scroll pane with a CBitMapPane inside it.  When
I scroll all the way to the right (or bottom), 2 problems show up:
  First, the BitMapPane stops scrolling when it fit the window frame insted
of the interior of the scroll pane,  so the 16 pixels on the edge don't show.
  Second, if I then enlarge the window, the BitMapPane doesn't "stick" to
the right and bottom edges so I get white rectangular regions on the edges
of the bit map's picture.

Has anyone had this happen to them?  What class methods do I need to adjust or
rewrite?

Blake










Path: ucivax!gateway
From: [e-mail] ("Kenneth B. Kirksey")
Subject: Bison & Flex
Full-Name: Kenneth B. Kirksey
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 7
Date: 16 Jan 92 18:01:32 GMT


I was wondering if anyone has fixed the Think C versions of bison and flex
that are in the archives so that they will compile without modification
under Think C 5.0.  I just wanted to see if someone else had already done
the work before I tried it.

                                  Ken










Path: ucivax!gateway
From: [e-mail] (Daryl Spitzer)
Subject: SPLAsh
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 8
Date: 16 Jan 92 20:38:22 GMT

Are any of you a member of SPLAsh (The Symantec Programming Languages
Association)?  Is it worth it?  Recommendations, warnings?
--
-------------------------------------------------------------------
 Daryl Spitzer                    "Life isn't just, life just is."
 Vancouver, Canada                         -- Me  (I think.)
 [e-mail]
-------------------------------------------------------------------










Path: ucivax!gateway
From: [e-mail]
Subject: SPLAsh
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 11
Date: 17 Jan 92 02:04:19 GMT


>Are any of you a member of SPLAsh (The Symantec Programming Languages
>Association)?  Is it worth it?  Recommendations, warnings?

  I joined at least a year ago, maybe two. I can only find two mailings
from them of any substance in my records. Unless they plan on getting
their act together, I'd say that they're not worth it.

-David












Path: ucivax!gateway
From: [e-mail] ("Haseen I. Alam")
Subject: ColorToolBox.h
Message-ID: <[e-mail]>
X-Mailer: ELM [version 2.3 PL11]
Newsgroups: fa.think-c
Lines: 36
Date: 17 Jan 92 04:19:20 GMT


 Hi there,

     I just ftp-d the source code for the Simple Raster Graphics Package
     (SRGP) and was trying to compile it under ThinkC 5.0.2.  First they
     asked to pre-compile a HEADERS file, but the compiler complains about
     the #include <ColorToolbox.h> statement, saying that it can't open the
     ColorToolbox.h file.

     Has anyone compiled this under ThinkC 5.0 with success?  This source
     accompanies the book "Computer Graphics: Principles and Practice," by
     Foley, vanDam, Feiner, and Hughes.  Am I missing some files from this
     distribution?

     Another error is that DrawText and SRGP__error are said to have "invalid
     redclarations."  I tried to find the other definitions with the search
     but could not find another declaration.

     ThinkC says that prototype is required for plot_with_line_style.  Can't
     find its definition anywhere.

     Now here is the most interesting one.  How do I read this if statement,
     given the following declarations?  Again it asks for the prototype for
     the last call.

     DECLARE funcptr         srgp__resizeCallback;
     int www, hhh
     if (srgp__resizeCallback)
        (*srgp__resizeCallback) (www, hhh);

     Thanks in advance.
 Haseen.
 .-------------------------------------------------------------------------.
 | "If you think I am expensive, wait  | email: [e-mail]        |
 |     till you hire an amateur!"      |    or  [e-mail] |
 `-------------------------------------------------------------------------'










Path: ucivax!gateway
From: [e-mail] (Ephraim Vishniac)
Subject: Re: ColorToolBox.h
Message-ID: <[e-mail]>
In-Reply-To: Your message of "17 Jan 92 04:19:20 GMT."
             <[e-mail]>
Newsgroups: fa.think-c
Lines: 38
Date: 17 Jan 92 13:15:00 GMT


   From: "Haseen I. Alam" <[e-mail]>
   Date: 17 Jan 92 04:19:20 GMT

     I just ftp-d the source code for the Simple Raster Graphics Package...

     Another error is that DrawText and SRGP__error are said to have "invalid
     redclarations."  I tried to find the other definitions with the search
     but could not find another declaration.

Two possibilities: There is a prototype somewhere, and it conflicts
with the actual definition, or (if you have "infer prototypes" turned
on) the usage of the function conflicts with its definition.

     ThinkC says that prototype is required for plot_with_line_style.  Can't
     find its definition anywhere.

     Now here is the most interesting one.  How do I read this if statement,
     given the following declarations?  Again it asks for the prototype for
     the last call.

     DECLARE funcptr         srgp__resizeCallback;
     int www, hhh
     if (srgp__resizeCallback)
        (*srgp__resizeCallback) (www, hhh);

Think of it this way:

   if (srgp_resizeCallback != NULL) {
    (*srgp_resizeCallback)(www, hhh);
   }

You need a prototype because funcptr is (I imagine) an unprototyped
pointer to function returning int. But srgp_resizeCallback has
parameters and no return value, so its type is really "void
(*srgp_resizeCallback)(int www, int hhh);". My syntax may be somewhat
off. I always have trouble with prototyping function pointers.











Path: ucivax!gateway
From: [e-mail] (Mark Nagel)
Subject: ARCHIVE: THINK C 5.0.2 + TCL 1.2.2 updaters
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Reply-To: [e-mail]
Lines: 28
Date: 17 Jan 92 17:07:11 GMT

Date: Fri, 17 Jan 92 08:08:49 EDT
From: "David S. McCormick" <[e-mail]>
Subject: Upload of combined Think C and TCL update

Mark:

I just transferred a combination of the Think C 5.0.2 and
TCL 1.1.2 in a binhex'ed self-extracting archive to
/incoming

This is a combination of new Debugger, Think C app patcher
v5.0.{0,1} => v5.0.2, and the v1.1.2 upgrade of the Think Class Library
in C.

Other people can send it to sumex and/or umich if they want.
As previously indicated, the other file I uploaded is just the
Think C upgrade.

Cheers,
David S. McCormick
[e-mail]

Bldg. 54-1016
MIT-EAPS Geology
Cambridge, MA  02139
617-253-5747

[saved as: /mac/think-c/symantec/502+112-updaters.hqx; 608K]










Path: ucivax!gateway
From: [e-mail] (Douglas Yarrington)
Subject: Re: Bison & Flex
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>; from "Kenneth B. Kirksey" at Jan 16, 92 6:01 pm
X-Mailer: ELM [version 2.3 PL0]
Newsgroups: fa.think-c
Lines: 27
Date: 17 Jan 92 21:04:58 GMT

Ken,

> I was wondering if anyone has fixed the Think C versions of bison and flex
> that are in the archives so that they will compile without modification
> under Think C 5.0.  I just wanted to see if someone else had already done
> the work before I tried it.

I edited the Bison file bison.simple to get the *.tab.c files to work
with Think C 5.0.

Add the following includes to the begining of bison.simple:
#include <stdlib.h>
#include <string.h>

Also in bison.simple, search for bcopy and replace with memmove (3
occurances), search for alloca and replace with malloc (3 occurances.)

I just did this yesterday, and I got it to compile, but I'm not sure
if I've handled the memory correctly. I believe alloca allocates
memory diffrently than malloc, but I didn't check it.

Hope this helps. And if I've done something wrong, please let me know.

--douglas

_______________________________________________________________________________
 Douglas Yarrington                                 [e-mail]










Path: ucivax!gateway
From: [e-mail] (Nick Rothwell)
Subject: Re: Plenty Questions
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 29
Date: 17 Jan 92 22:04:59 GMT

[Attempt #3]

[Attempt #2]

>Using the Mac Primer, I have successfully cleared the screen (mimicking the
>flying line demo),

Congratulations, it sounds like you've successfully written a totally
non-portable, user-hostile, nonstandard Macintosh program.

>Do pixels reside in a specific area of memory?  If so, what hexidecimal range
>would it be or how could I find out?

Let's just say this is a meaningless question, what with multiple monitors
and bit depths, System Extensions which redefine the drawing environment,
add-on graphics accelerating hardware, and a little-known feature of the
Macintosh called the Window Manager.

>Are there any references/sample programs that I could access to find out more
>about graphics?  Specific programs on info-mac, a book such as the Mac Primer,
>any information would be greatly appreciated.

Flames aside - you're going about this the wrong way. Treat yourself to
some of the Inside Macintosh books (I and II for starters, V if you're
interested in colour). And try to forget this setting-a-pixel-in-memory
stuff - It was just a bad dream you had.

        Nick.











Path: ucivax!gateway
From: [e-mail] (Nick Rothwell)
Subject: Re: Bug in TC5.0.1 Compiler....
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 16
Date: 17 Jan 92 22:05:33 GMT

[Attempt #4]

[Attempt #3]

[Attempt #2 - mail problems at this end]

>    What is bad about disabling the quit menu option is when your
>little program gets stuck in some kind of bug-induced loop for which you
>can not escape....

I assume this is a follow-up to my comments about TC5.0.1 allowing itself
to be quitted from the Finder even when running projects, but I'm afraid I
don't understand what you're trying to say.

        Nick.











Path: ucivax!gateway
From: [e-mail] ("R. Mark Fleming")
Subject: re: sicn list manager LDEF
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 192
Date: 17 Jan 92 22:56:17 GMT

Here's an example of LDEF for SICN with Text.   I just updated it to
also work with the current Hilite Color.   I have not used it or test
the change, I have had it for sometime just incase I need it.

/*
    sicn ldef.c  v1.0
    Copyright 1989 Josh Pritikin
    All rights reserved.

    This LDEF may be used freely in any programming project, no string attached.

    This LDEF will let you display text as with a normal LDEF except you can
    also attach SICN's to each item.  I wrote this to emulate the one in SFDialog.

    The data format is as follows:

    char    index into the SICN resource
    Pstr    the item's text

    The SICN used is the one that has the same ID as the LDEF.  The SICN id
    could be uptained in a more versital way but I didn't want to spend too
    much time on this mini-project.

    If you add color capabilities or figure out a better way to specify the
    SICN id, send me a copy of your source.

Add change for color see line marked with RMF

    Change History

12.19.89    Created and tested.
12.19.89    v1.0 Release
12.19.89    Now the high bit of the sicn index indicates whether to hilite the
            item or not.  Set means disabled.
12.22.89    If the item is disabled you can't select it anymore. Your appl will
            have to check because the List Mgr thinks the item is selected but
            it wont show on screen.
12.19.89    v1.02 Release - (sorry 'bout not making this the first release)

    I can be reached at different speed at:

fast->            (every day)
    internet: [e-mail]
    AppleLink: [e-mail]@DASNET#
    CIS: >INTERNET:[e-mail]
slow->            (once a week)
    GEnie: J.Pritikin
    AppleLink: Josh.P
very slow->        (once a month, if yer lucky)
    CIS: 70771,2131
*/

typedef unsigned char    uchar;

/* #define testing */

#ifdef testing
pascal void ldef128(int message, Boolean select, Rect *bounds, Cell cell,
    int DataOff, int DataLen, ListHandle lhandle)
#else
pascal void main(int message, Boolean select, Rect *bounds, Cell cell,
    int DataOff, int DataLen, ListHandle lhandle)
#endif
{
    Rect    savedOrig;
    GrafPtr    aPort, saveport;
    int        savedFont, savedSize, savedMode, savedPenVis;
    Style    savedFace;
    PenState    ps;
    char *p;   /* Pointer used to clear Color QD flag RMF */

    if (message == lDrawMsg || message == lHiliteMsg) {
        GetPort(&saveport);
        aPort = (**lhandle).port;
        SetPort(aPort);

        savedOrig = aPort->portRect;
        SetOrigin(0,0);
        savedPenVis = aPort->pnVis;
        aPort->pnVis = 0;
        GetPenState(&ps);

        savedFont = aPort->txFont;
        savedSize = aPort->txSize;
        savedFace = aPort->txFace;
        savedMode = aPort->txMode;
        TextFont(systemFont);
        TextSize(0);
        TextFace(0);
        TextMode(srcOr);
    }

    switch (message) {
    case lInitMsg:
        {
        int        id;
        long    type;
        Str255    name;

        GetResInfo((**lhandle).listDefProc, &id, &type, &name);
        (**lhandle).userHandle = GetResource('SICN', id);
        HPurge((**lhandle).userHandle);

        break;
        }

    case lDrawMsg:
        {
        Handle    sicns;
        uchar    index;
        Boolean    hilited;

        EraseRect(bounds);
        MoveTo(bounds->left + 22, bounds->bottom - 4);
        DrawText(*(**lhandle).cells, DataOff+1, DataLen-1);

        index = *(*(Handle)(**lhandle).cells + DataOff);
        if (index >= 0x80) {
            index = index & 0x7f;
            hilited = false;
        } else
            hilited = true;

        if (btwn(index, 0, 5)) {
            sicns = (**lhandle).userHandle;
            if (sicns) {
                LoadResource(sicns);
                if (*sicns) {
                    BitMap    bmap;
                    Rect    r;

                    HNoPurge(sicns);
                    HLock(sicns);

                    bmap.baseAddr = *sicns+(index * 32);
                    SetRect(&bmap.bounds, 0, 0, 16, 16);
                    bmap.rowBytes = 2;

                    r = bmap.bounds;
                    OffsetRect(&r, bounds->left+3, bounds->top);

                    CopyBits(&bmap, &aPort->portBits, &bmap.bounds, &r, srcOr,
                        nil);

                    HUnlock(sicns);
                    HPurge(sicns);
                }
            }
        }

        if (!hilited) {
            long    gray[2];

            PenMode(patBic);
            gray[0] = gray[1] = 0xaa55aa55;        /* 50% gray */
            PenPat(gray);
            PaintRect(bounds);
        }

        if (!select)
            break;
        }

    case lHiliteMsg:
        {
          p = (char *) 0x938;   /* Flag Invert Color */
          *p = *p & 0x7f;  /* HiLiteMode for Color QD - RMF  */
        if (*(*(Handle)(**lhandle).cells + DataOff) < 0x80)
            InvertRect(bounds);
        break;
        }

    case lCloseMsg:
        {
        if ((**lhandle).userHandle)
            ReleaseResource((**lhandle).userHandle);
        break;
        }
    }

    if (message == lDrawMsg || message == lHiliteMsg) {
        SetPenState(&ps);
        aPort->pnVis = savedPenVis;
        aPort->portRect = savedOrig;
        TextFont(savedFont);
        TextSize(savedSize);
        TextFace(savedFace);
        TextMode(savedMode);

        SetPort(saveport);
    }
}










Path: ucivax!gateway
From: [e-mail] (Wade Williams)
Subject: HyperCard XFCN
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 59
Date: 17 Jan 92 23:38:14 GMT
X-Envelope-to: [e-mail]

Ok, here's one:

The following code works if I take out the else statement.  That is, it
returns the correct volume name if the error checking provided by the else
clause is removed.  If I leave the error checking code in and generate an
error (by not inserting a disk) it works correctly by reporting no such
volume.

However, if leave the error checking code in and put a disk in, instead of
returning its name, it returns the "A" with the degree symbol over it.
(Shift-option-A or 0x81 if you want to see what it is).

Anybody have any guess why this would return the correct volume name when
the else clause is left out and gibberish when it is included?

/**************************** Main ********************************/

pascal void main( paramPtr )
XCmdPtr    paramPtr;
{
      StringPtr        volName, theError;
      short            drvNum;
      short            vRefNum;
      long            freeBytes;
      OSErr            iErr;

      drvNum=1; /* 1 indicates first internal floppy */
      iErr = GetVInfo ( drvNum, volName, &vRefNum, &freeBytes );
      if (!iErr)
      {
            paramPtr->returnValue=PasToZero(paramPtr, volName );
      }
      else
      {
            switch (iErr)
            {
               case -35:  /*  no such volume */
                     theError=(StringPtr)"\pError:  No such volume.";
                     paramPtr->returnValue=PasToZero(paramPtr, theError );
                     break;
                case -50:  /*  bad drive number */
                     theError=(StringPtr)"\pError:  Bad drive number.";
                     paramPtr->returnValue=PasToZero(paramPtr, theError );
                     break;
            }
       }

}

/********************************/

-------------------------------------------------------------------------
Wade Williams                             "Any escape might help to smooth the
User Services Specialist            unattractive truth, but the suburbs
Academic Computing                     have no charms to soothe the restless
Auburn University                      dreams of youth." (N. Peart)
[e-mail]
-------------------------------------------------------------------------











Path: ucivax!gateway
From: [e-mail] ("Russell S. Finn")
Subject: Re: Bison & Flex
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 23
X-Mts: smtp
Date: 18 Jan 92 01:57:41 GMT

I did the original port of Bison and Flex to THINK C 4.0 two years
ago, but have not done anything with it since then.

> Add the following includes to the begining of bison.simple:
> #include <stdlib.h>
> #include <string.h>

This will be necessary since THINK C 5.0 is fully ANSI-compliant.

> Also in bison.simple, search for bcopy and replace with memmove (3
> occurances), search for alloca and replace with malloc (3 occurances.)

This was also necessary, it turns out, in the originally posted
version, unless you take the implementation of "alloca" out of Bison
and include it with the code that uses the Bison output.  (Does that
make sense?)

If anyone else discovers something else that needs to be adjusted, I'd
appreciate knowing about it (although I'll see anything posted to this
list sooner or later).

-- Russell S. Finn
[e-mail]










Path: ucivax!gateway
From: [e-mail] (John J Chew)
Subject: Re:  scroll panes
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 53
Date: 18 Jan 92 04:37:11 GMT

In <[e-mail]> Blake Fordham
  <[e-mail]> writes:

> I just started using TCL and I've run into a small idiosyncrasy that I
> can't track down.  I have a scroll pane with a CBitMapPane inside it.  When
> I scroll all the way to the right (or bottom), 2 problems show up:
>   First, the BitMapPane stops scrolling when it fit the window frame insted
> of the interior of the scroll pane,  so the 16 pixels on the edge don't show.
>   Second, if I then enlarge the window, the BitMapPane doesn't "stick" to
> the right and bottom edges so I get white rectangular regions on the edges
> of the bit map's picture.
>
> Has anyone had this happen to them?  What class methods do I need to adjust or
> rewrite?

Haven't noticed the first problem but the following code solves the second
problem for me:

/* ResizeFrame() - resize frame */
void CTerminalPane::ResizeFrame(Rect *delta)
    {
    short    height;
    long    left;
    Point    newposition;
    long    top;
    short    width;

    inherited::ResizeFrame(delta);

    GetFramePosition(&left, &top);
    GetFrameSpan(&width, &height);

    newposition.h = left;
    newposition.v = top;
    if (width > bounds.right) /* scrollpane is wider than panorama */
        newposition.h = 0;
    else if (left + width > bounds.right) /* ugly white space at right */
        newposition.h = bounds.right - width;
    if (height > bounds.bottom) /* scrollpane is taller than panorama */
        newposition.v = 0;
    else if (top + height > bounds.bottom) /* ugly white space at bottom */
        newposition.v = bounds.bottom - height;
    if (newposition.h != left || newposition.v != top)
        ScrollTo(newposition, TRUE);
    }

John
--
John J. Chew, III                            * [e-mail]
AIS/Berger-Levrault * phone [phone]  * [e-mail]
18, rue des Glacis  * fax   [phone]  * [e-mail]
F-54017 Nancy Cedex * telex BL NANCY 960 212 * [e-mail]
"Les arbres sont souvent en cause dans les accidents de la circulation."










Path: ucivax!gateway
From: [e-mail] (Phil Shapiro)
Subject: ProcPtr parameters v2
Message-ID: <[e-mail]>
In-Reply-To: "Mr. Neb"'s message of 13 Jan 92 20:44:37 GMT <[e-mail]>
Newsgroups: fa.think-c
Lines: 42
Date: 18 Jan 92 14:44:46 GMT

>>>>> On 13 Jan 92 20:44:37 GMT, "Mr. Neb" <[e-mail]> said:
 >     This is the type of thing that I want to implement:

 > void foo(ProcPtr BarProc){
 >     int a;
 >     ...
 >     a=BarProc();
 >     ...
 > }

 > int BarOne(void){ }

 > int BarTwo(void){ }

 > main(){
 >     foo(BarOne);
 >     foo(BarTwo);
 > }

Instead of using the type "ProcPtr", you should create your own
procedure pointer type using a typedef statement. For example,

    typedef int (*BarProcPtr) (void);

This defines the typename "BarProcPtr" as a pointer to a function that
doesn't take any arguments and returns an integer. You can use it to
declare foo's argument:

    void foo(BarProcPtr barProc)
    {
        int a = barProc();
    }

I would recommend that you do not use the type "int", use "short" or
"long" instead. Using int will prevent you from porting your code
between THINK C and MPW C, if the need ever arises.

    -phil
----
   Phil Shapiro                           Technical Support Analyst
   Language Products Group                     Symantec Corporation
        Internet: [e-mail]










Path: ucivax!gateway
From: [e-mail] (Phil Shapiro)
Subject: When should I avoid breaking into the Think Debugger?
Message-ID: <[e-mail]>
In-Reply-To: Craig Hollabaugh's message of 13 Jan 92 16:50:55 GMT <[e-mail]>
Newsgroups: fa.think-c
Lines: 37
Date: 18 Jan 92 14:54:56 GMT

>>>>> On 13 Jan 92 16:50:55 GMT, Craig Hollabaugh <[e-mail]> said:

>>> Are there any points in a typical Mac application when I should avoid
>>> breaking into the Think Debugger?

 > Here is a debugging tip: Don't single step across Event functions.
 > I found that AcceptHighLevelEvent doesn't return appropriate values
 > if you stop before it and step across. Other Event functions
 > probably behave similiarly.  So my tip is put your stops after
 > Event functions.

Since the THINK C debugger (sort of) uses the Event Manager to switch
between your application and the debugger, you may "lose" events if
you try to step over a call to {Wait,Get}NextEvent, or the high-level
event manager routines.

If you want to avoid *crashing* the debugger, don't do this:

 - put a breakpoint/Debugger() statement in any bit of code that can
 execute at interrupt time, like a device completion routine (File
 Manager, Sound Manager, any PBxxx call). This also includes VBL or
 Slot Manager tasks.

 - put a breakpoint in any bit of code that can execute as part of a
 call to a non-reentrant toolbox manager. For example, don't put
 breakpoints in routines that may be called from your custom WDEF,
 since the Window Manager isn't reentrant.

 - don't try to put breakpoints inside, or step over, calls to
 OpenPicture, OpenRgn, and OpenPoly. These parts of QuickDraw are also
 non-reentrant.

    -phil
----
   Phil Shapiro                           Technical Support Analyst
   Language Products Group                     Symantec Corporation
        Internet: [e-mail]










Path: ucivax!gateway
From: [e-mail] (geoff george)
Subject: ProcPtr parameters v2
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 138
Date: 22 Jan 92 06:43:14 GMT

As I read the headers for Think C 5.01 (which are supposed to be the
same as those for the latest MPW, but which have conditional compiles in
them so TC stuff can differ from MPW stuff in a few cases), ProcPtr is
defined as (void *) in Types.h:

    typedef void *ProcPtr;

Under MPW, it's:

    typedef long (*ProcPtr)();

How you declare your functions depends on just what you want to do with
them. If you don't want to pass a function to toolbox calls, you can get
by with plain C declarations:


    void foo (int (* BarProc) (void));    /* declaration */
    void foo (int (* BarProc) (void)) {    /* definition, i.e. body */
            int a;
            ...
            a = BarProc ();    /* ANSI C allows this; old-style C
                   would require: a = (* BarProc) ();
                */
    }


    int BarOne (void){        ...    }
    int BarTwo (void){        ...    }

    main(){
            foo (BarOne);    /* "foo (& BarOne)" would also be ok,
            foo (BarTwo);       just like with arrays */
            ...
    }


The precedence of operators in C requires the extra parentheses around
the parameter BarProc and its star.

If you want to have a function which is called by the toolbox and also
by your own code, declare it the way Inside Mac says to; e.g. for a
scroll bar action proc I use: (this is from working code; I actually
declared this particular routine static, but that's irrelevant)

    pascal void SBActionProc (ControlHandle sb, short part);
    pascal void SBActionProc (ControlHandle sb, short part) { ... }

Since the formal type of the third argument to the Toolbox trap
TrackControl() is ProcPtr, I call it like so:

    TrackControl (whichControl, where, (ProcPtr) SBActionProc);

Note the cast. This isn't needed with Think C, since ProcPtr is (void *)
and any pointer can be assigned to, or passed as, a (void *); but under
another C compiler (TC is all I've ever used on the Mac, by maybe one
day...) the cast might be required; it certainly would under MPW C,
where ProcPtr is defined as a pointer to a function taking unknown
arguments and returning a long. If I wanted to pass a pointer-to-
SBActionProc() to my own function which would then call it, I'd use:


    void foo (void (* barProc) (ControlHandle, short));
    void foo (void (* barProc) (ControlHandle, short)) {
        ControlHandle which; short part;
        ...
        (* barProc) (which, part);
        }


    foo (SBActionProc);        /* call in, say, main() */


or more readably:


    typedef void (* SBProc) (ControlHandle, short);

    void foo (SBProc barProc);
    void foo (SBProc barProc) {
        ControlHandle which; short part;
        ...
        (* barProc) (which, part);
        }


    foo (SBActionProc);        /* call in, say, main() */


This code (either case) preserves all type-checking of parameters, even
requiring that the signature of SBActionProc() match that of (* barProc)
(under TC 5; TC 4 wasn't so smart). I could declare the parameter
barProc to be a ProcPtr instead, but then I'd have to cast it to the
right function-pointer type before I could call the function it pointed
to. This would be ugly:


    void foo (ProcPtr barProc) {
    ...
    (* (void (*) (ControlHandle, short)) barProc) (which, part);
    }


or not quite so bad:


    typedef void (* ActionProcPtr) (ControlHandle, short);

    void foo (ProcPtr barProc) {
        ActionProcPtr app;
        ...
        app = (ActionProcPtr) barProc;
        app (which, part)
    }


In either of these last two cases you wouldn't get type-checking on the
parameter barProc, nor on the parameters you'd pass to the function
barProc points to; you've defeated the type-checking with casts, so that
if you were to call "foo (bar2)" where bar2() required three parameters,
bar2() would recieve garbage; foo() would put a ControlHandle and a
short on the stack, and bar2() would treat that space as though it
contained whatever its formal parameters where, resulting in chaos at
best and trashing memory at worst, depending on exactly what bar2() does
with its parameters. The compiler cannot warn you about this, as it can
in the third and fourth cases back.

Hope this helps. There might be typos, it's late; write back if you
suspect any, or have more questions.

geoff
--
geoff george    [e-mail]        (my name)
            or  [e-mail]   (a touch of warmth from GaTech OCS)

"Ordinary f---ing people - I hate 'em. Ordinary person spends his life
avoiding tense situations; repo man spends his life getting INTO tense
situations."











Path: ucivax!gateway
From: [e-mail] (mcilroy_p_w_a)
Subject: Please Remove My Name from the THINK-C MAILING LIST
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
X-Vms-To: R11F::ICS.UCI.EDU::THINK-C
Lines: 11
Date: 22 Jan 92 19:13:23 GMT

From:    NAME: P W A MCILROY         [DNR33 ]
    FUNC: DNR33
    TEL: [phone]                      <MCILROY P W A AT WEB AT WEBCS>
To:    [e-mail]@unet


Please Remove My Name from the THINK-C MAILING LIST

Many thanks,

Paul McIlroy.










Path: ucivax!gateway
From: [e-mail] (Daryl Spitzer)
Subject: CPrinter::GetPrintRecord()
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 11
Date: 23 Jan 92 08:05:05 GMT

The documentation for CPrinter::GetPrintRecord() states "other objects should
treat this record as read-only"...why?  Would it be a mistake to get the print
record and then set pIdleProc to my own procedure?  If so, what would be the
right way to do it?  Do I really have to override CDocument::MakePrinter() and
build my own print record?
--
-------------------------------------------------------------------
 Daryl Spitzer                    "Life isn't just, life just is."
 Vancouver, Canada                         -- Me  (I think.)
 [e-mail]
-------------------------------------------------------------------










Path: ucivax!gateway
From: [e-mail] ("Eric W. Sink")
Subject: Flex and Byacc
Message-ID: <[e-mail]>
X-Mailer: ELM [version 2.3 PL11]
Newsgroups: fa.think-c
Lines: 10
Date: 23 Jan 92 18:34:47 GMT

Someone mentioned doing ports of flex and byacc to Think C 5,
from the 4.0 versions.  Did anyone finish this ?  How about
a port of flex 2.3 (the Mac version is 2.1 beta)?

Just curious...

--
Eric W. Sink,  Spatial Analysis and Systems Team
USACERL, P.O. Box 9005, Champaign, IL 61826-9005
1-800-USA-CERL x449,   [e-mail]










Path: ucivax!gateway
From: [e-mail]
Subject: Host-id and Crypt
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 20
Date: 23 Jan 92 19:00:50 GMT


Two questions:

    1.  Is there a Macintosh equivalent to the host-id that is available
        on the Sun?  Is there a toolbox call that can be used to
        get this string?

        On the Sun, the host-id is a string that is embedded in the ROM
        (I believe) and can be used to uniquely identify a workstation.
        I'm trying to find out if the Mac's ROM has an id string encoded
        into it that is unique to each Mac and if so, how to get it.

    2.    Is there something comparable to the Unix crypt/decrypt systems calls
        available on the Mac?  Has anyone ported the Unix crypt command?


Thanks.

Riyaz
[e-mail]










Path: ucivax!gateway
From: [e-mail] (Wade Williams)
Subject: XCMDs and XFCNs
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 22
Date: 23 Jan 92 20:08:52 GMT
X-Envelope-to: [e-mail]

Two questions:

The HyperCard Scripting guide says that XCMDs cannot use string literals.
Does that mean I can't use a statement like:

StringPtr  theError;

theError=(StringPtr)"\pError:  Disk Full";

Also, it says that string literals *can* be used when compiled in MPW 3.0
or later with the -b switch.  How does that apply to THINK C 5.0.2?



-------------------------------------------------------------------------
Wade Williams                             "Any escape might help to smooth the
User Services Specialist            unattractive truth, but the suburbs
Academic Computing                     have no charms to soothe the restless
Auburn University                      dreams of youth." (N. Peart)
[e-mail]
-------------------------------------------------------------------------











Path: ucivax!gateway
From: [e-mail] (Jonas Barklund)
Subject: Flex and Byacc
Message-ID: <[e-mail]>
In-Reply-To: Eric W. Sink's message of 23 Jan 92 18:34:47 GMT <[e-mail]>
Newsgroups: fa.think-c
Lines: 7
Date: 23 Jan 92 22:02:51 GMT

I have ported flex.2.3.7 to Think C 4.0. I have had no trouble
using the application also together with Think C 5.0.
If noone else has already done this, and uploaded it somewhere
reachable I will be happy to do so.

Jonas Barklund, Computing Science Department, Uppsala University
Email [e-mail], phone [phone], fax [phone]










Path: ucivax!gateway
From: [e-mail] ("Julian E. Gomez")
Subject: THC 502 updater
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 4
Date: 24 Jan 92 03:00:11 GMT

Has anyone found the trick to make the TCL updater work properly?
No matter what I do I end up with a new folder instead of having
the files replaced. I even tried it with a freshly installed copy
from the 5.0 disks.










Path: ucivax!gateway
From: [e-mail] (Paul Potts)
Subject: Re:  THC 502 updater
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 13
Date: 24 Jan 92 13:53:34 GMT


The trick is, before clicking "extract," go to inside the top-level folder
of the THINK C package. If you have followed the manual, you have a folder
called "Development" or something like that with a "THINK C 5.0 Folder,"
"TCL 1.1 Demos," "THINK C 5.0 Demos," and "THINK C 5.0 Utilites" in it.
Extract while set to your "Development" folder.
The extracter will then give you a couple of options for replacing files:
replace just the first one, or replace them all. You want to replace them
all. It will find the 33 or so files and replace them.
This is, by the way, all clearly stated in the README file that comes with
the updater.
-Paul Potts-
[e-mail]










Path: ucivax!gateway
From: [e-mail] (Paul Potts)
Subject: THC 502 updater
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 10
Date: 24 Jan 92 15:02:56 GMT


Sorry, when I said
>The extracter will then give you a couple of options for replacing files:
replace just the first one, or replace them all. You want to replace them
all.

By "all" I meant "all the files which it is meant to replace," not
"all the files in the TCL." Oops... : >

-Paul-










Path: ucivax!gateway
From: [e-mail] (Craig MacFarlane)
Subject: Quicktime and Think C
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 9
Date: 24 Jan 92 17:38:33 GMT

I'd like to incorporate Quicktime shorts into a piece of software that
I am developing.  Does anybody know where to get some documentation
on how to use Quicktime?  I have the interfaces from ftp.apple.com, but
there is no documentation from Apple to go along with them.  Can these
interfaces be used without modification with Think C?

Thanks,
Craig MacFarlane
[e-mail]










Path: ucivax!gateway
From: [e-mail] (John Cartwright)
Subject: SFGetfile, SFPutfile
Message-ID: <9201241833.AA14315@picea>
Newsgroups: fa.think-c
Lines: 10
Date: 25 Jan 92 18:21:09 GMT


Hello all,

I am an extremely novice programmer, but I am looking for a simple example of
how to use SFGetfile and SFPutfile in a program that opens a user-specified
text file, does some processing, and then writes out to a user-specified text
file.  Nothing fancy at all.  Any suggestions would be most appreciated!

--john
[e-mail]










Path: ucivax!gateway
From: cmiller@laurel (Craig Miller)
Subject: The SPLAsh Story?
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 33
Date: 27 Jan 92 16:49:42 GMT

To:  Greg Dow
     SPLAsh Resources
     [e-mail]

cc:  [e-mail]
     (the Think C mailing list)
Dear Greg,

What's the story?  After joining this "association"
last summer with hopes and interest and a payment
of a very reasonable $30 or so, I have received
exactly one thing:  a beautiful little blue
membership card stating that I am member #1826,
have been a member since "Sep 91", "Good Thru Sep
92", and finally "Last Issue  #7".  Nothing else.
No other communication, no issues of anything.
On the other hand, I have heard stories of similar
non-communication via email.

I am not angry, just disappointed.

It would be very helpful for me and others to hear
from you.  What's the real story?  Who are you,
what have you done, what are you doing, what are
your plans for the future of this "assocation"?

Sincerely,
-----------------------------------------------------------------------
Craig D. Miller, Computer Programmer          \  [e-mail]
Scientific Reasoning Research Institute (SRRI) \      tel. [phone]
306 Hasbrouck Lab                               \
University of Massachusetts, Amherst, MA  01003  \                  USA
-----------------------------------------------------------------------










Path: ucivax!gateway
From: [e-mail] (Craig Hollabaugh)
Subject: setjmp, longjmp, and objects
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 16
Date: 27 Jan 92 17:49:13 GMT


Folks,
Standard Libraries Reference page 260 (setjmp) note says
you can't use setjmp() and longjmp() in object methods.

why is that? I have found that mallocs after the longjmp
tend to bomb, which leads me to believe that memory allocation,
indirect object classes, and the longjmp aren't compatible.

If someone could offer insight I would appreciate it. I have
a large simulation program that uses setjmp/longjmp for error
handling and only recently discovered that it won't work. ugh!!

Craig Hollabaugh
Analog Microelectronics, Georgia Tech
[e-mail]










Path: ucivax!gateway
From: [e-mail] (Rick Holzgrafe)
Subject: What's in the 5.0.2 update?
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 14
Date: 27 Jan 92 18:05:40 GMT

 Internet Mail          What's in the 5.0.2 update?
I have a project near completion that uses ThC 5.0.1 and the accompanying
upgrade to the TCL. I'm a little nervous about upgrading to 5.0.2 this late in
the game. Does anyone have a list of the changes it makes to the TCL?

-----------------------------------------------------
Rick Holzgrafe   [e-mail]   AppleLink HOLZGRAFE1
     {sun,voder,nsc,mtxinu,dual}!apple!rmh
Apple Computer, Inc.
20525 Mariani Ave. MS: 3-PK
Cupertino, CA 95014













Path: ucivax!gateway
From: [e-mail] (Rick Holzgrafe)
Subject: "Cursed" Source File
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 36
Date: 27 Jan 92 18:20:44 GMT

 Internet Mail          "Cursed" Source File
A bug in a recent project of mine was trashing memory that didn't belong to it
- all too easy to do on the Mac. I fixed the bug, but I started having frequent
crashes in Think C, even after a reboot and before trying to run any of my
code. For a long time I suspected that the project file had been trashed by the
old bug, but repeated efforts to create a guaranteed brand-new, clean,
built-from-scratch, uncorrupted project file didn't seem to help. Eventually I
realized that the symptoms always seemed to occur during or after editing one
particular source file.

I think I've finally exorcised the demon: the resources in the source file were
corrupt. These resources include the list of markers for the file, and perhaps
other things as well. After I used ResEdit to remove all resources from that
file, the troubles went away and have not recurred.

The symptoms: Various kinds of funny behavior from Think C, including
mysterious crashes, demands to "remove objects" from a project file so new that
it has never had any, bombs while running your code under the debugger that
occur BEFORE your code actually starts up, "Bad ZREF" complaints, and others.
One symptom seems very characteristic: the text in the affected source file
keeps getting subtly corrupted, as little one- to four-byte chunks of text get
replaced with one- to four-byte chunks of garbage.

So this is a cautionary tale: Think C has fragile project files AND fragile
source files that can be corrupted in persistent ways. Be careful.

-----------------------------------------------------
Rick Holzgrafe   [e-mail]   AppleLink HOLZGRAFE1
     {sun,voder,nsc,mtxinu,dual}!apple!rmh
Apple Computer, Inc.
20525 Mariani Ave. MS: 3-PK
Cupertino, CA 95014
     --- My opinions, not Apple's.













Path: ucivax!gateway
From: [e-mail] (Qingkuang Yang)
Subject: (none)
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 1
Date: 28 Jan 92 03:32:02 GMT

subscribe Yang Qing-Kuang










Path: ucivax!gateway
From: [e-mail]
Subject: (none)
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Original-From: cblph!jbr (j.a.brownlee)
Lines: 36
Date: 28 Jan 92 12:40:37 GMT

The limitations of the Mac's Memory Manager with respect to allocating many
pieces of memory have recently been discussed again on c.s.m.p.  The timing
of the discussion coincides with a problem I am having using the TCL to create
a lot of objects.  Before I outline the problem, let me mention that I'm using
TC 5.0.1 (not 5.0.2 yet) on an 8 MB IIcx.

My project creates one primary object that the user can edit.  It is an
aggregation of about 3000 small objects, most taking up only a few bytes.
Of course, doing this the standard way with indirect objects is unbearably
slow, and gets slower and slower as more objects are allocated, which is the
behavior one expects from the Memory Manager in such a situation.

My question is this: what is the best approach in TCL to get around this
problem?  I'd like a solution that is efficient, but that does not mess up the
encapsulation of the objects too badly.  For example, one solution I thought
of is to have the primary object allocate enough memory for all the smaller
objects and then parcel it out as the small objects are created.  The two
problems I see are that it would be tricky to allocate the memory in a
relocatable block (which I'd like to do, if possible) and have all of the
smaller objects get at the master pointer in the primary object.  Also, the
primary object might have to know too much about the smaller ones for my
comfort.  Would it be helpful to write my own new() in these cases?

One problem that complicates trying to do this in a modular way is the fact
that in TC 5.x, you can no longer use sizeof() on classes or objects.  I'm not
exactly sure why this limitation was added, but it has been very annoying to
me on several occasions.  I suppose one way to get around this is to wrap
each object's data members inside a structure, on which I can use sizeof().
This is a hassle, but it should be a practical solution.

Thanks in advance for any advice you can offer, everyone!

   ^      _   Joe Brownlee, Analysts International Corporation @ AT&T Bell Labs
  /_\  @ / `  471 E Broad St, Suite 2001, Columbus, Ohio 43215   [phone]
 /   \ | \_,  E-mail: [e-mail]     Who pays attention to what _I_ say?
 "Scotty, we need warp drive in 3 minutes or we're all dead!" --- James T. Kirk










Path: ucivax!gateway
From: [e-mail] (Iain Campbell)
Subject: MacTCP routines for Think C 5.0
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 48
Date: 28 Jan 92 19:06:45 GMT


Hi !

SHORT FORM:

   I'm trying to port some of my Unix/C code to the Mac.

   The code implements a information retrieval server on a TCP port.

   I need C routines to allow me to use the MacTCP drivers - can anyone
help ?



VERBOSE FORM:

I want simple routines to build connections and transfer blocks of data.

I've tried to get MacTCP to work with the code from Eudora, but that code
does
a lot of fancy stuff and I can't figure it all out.

I tried stripping the Eudora code to the bones and managed to get the
MacTCP driver
initialised, open a connection to a remote Unix box, but can't get it to
send data
or close the connection without 'hanging' my Mac.

Is there an Apple library or some such thing ?

I've now spent several days hacking, and have had enough, I give in, please
help !!

(Mac IIfx, System 7.0.0, MacTCP 1.1, Think C 5.0, Mac Programming
Experience ver 0.0.0)


===========================================================================
Iain Campbell                                          [e-mail]
Radio Schweiz AG
Laupenstrasse 18a                                    Tel: [phone]
CH-3008 Bern       (but I'm NOT Swiss)               Fax: [phone]
---------------------------------------------------------------------------
Even non-Scotsmen, without a word of Gaelic in there heads, can be heard
refering to their "whisky" by its original Gaelic "uisge" within a couple
of drams. What other spirit can claim such linguistic impartation?
===========================================================================











Path: ucivax!gateway
From: [e-mail] (Thomas Edward Van Lenten)
Subject: Creating Windows
Message-ID: <gdVjOYS00WC=[e-mail]>
Newsgroups: fa.think-c
Lines: 15
Date: 29 Jan 92 18:52:22 GMT

I'm starting up a project in Think C 5, and was wondering if there is
some easy way to create a window full of views.  The only option I see
right now is to create the views one at a time, by hand in the code.  I
was thinking of writting a function like the one in MacAPP that will
create the window and subviews from a 'view' rsrc; but there is no way
to create an object by name.  Has anyone else done something like this
who could point me in the right direction?

TVL
=========================================================
 Tom Van Lenten                         Special Projects
 [e-mail]          Carnegie Mellon University
 bitnet%"tv0c@andrew"                     Pittsburgh, PA
=========================================================











Path: ucivax!gateway
From: [e-mail] ("Russell S. Finn")
Subject: Re: Creating Windows
Message-ID: <[e-mail]>
In-Reply-To: Your message of "29 Jan 92 18:52:22 GMT."
             <gdVjOYS00WC=[e-mail]>
Newsgroups: fa.think-c
Lines: 22
X-Mts: smtp
Date: 30 Jan 92 01:05:05 GMT

> I'm starting up a project in Think C 5, and was wondering if there is
> some easy way to create a window full of views.  The only option I see
> right now is to create the views one at a time, by hand in the code.  I
> was thinking of writting a function like the one in MacAPP that will
> create the window and subviews from a 'view' rsrc; but there is no way
> to create an object by name.  Has anyone else done something like this
> who could point me in the right direction?

First of all, in TCL you probably want to create "panes", not "views";
the confusion in terminology is unfortunate, but in TCL "views" are
abstract classes for "things that appear on the screen", which include
windows as well.

Secondly, there already are functions to create panes (and many
objects that descend from them) from resources; see the definition of
CPane::IPaneRes (which uses a 'Pane' resource), and the discussion of
this topic in an early chapter of the Object-Oriented Programming
Reference (I don't have it in front of me, but it's the "How to use
the TCL" chapter -- 6, perhaps?).

-- Russell S. Finn
[e-mail]










Path: ucivax!gateway
From: [e-mail] (Thomas Edward Van Lenten)
Subject: Re: Creating Windows
Message-ID: <cdVrC=W00WC=[e-mail]>
In-Reply-To: <[e-mail]>
Newsgroups: fa.think-c
Lines: 23
Date: 30 Jan 92 03:41:01 GMT

Excerpts from mail: 29-Jan-92 Re: Creating Windows "Russell S.
Finn"@joplin (1121)
>Secondly, there already are functions to create panes (and many
>objects that descend from them) from resources; see the definition of
>CPane::IPaneRes (which uses a 'Pane' resource), and the discussion of
>this topic in an early chapter of the Object-Oriented Programming
>Reference (I don't have it in front of me, but it's the "How to use
>the TCL" chapter -- 6, perhaps?).

I know about this.  What I'm interested in doing is making a resource
that says 'put a pane of type CMyPane at this rect, and type CMyButton
at this rect'.  Hence my problem is how to take the name of the class
('CMyPane'), and create an object of that type on the fly.  Other
compilers have a method to create an object by name (a new() that takes
a Str255 as the parameter).  This is the ability that I'm trying to get.

TVL
=========================================================
 Tom Van Lenten                         Special Projects
 [e-mail]          Carnegie Mellon University
 bitnet%"tv0c@andrew"                     Pittsburgh, PA
=========================================================











Path: ucivax!gateway
From: [e-mail] (Eric Slosser)
Subject: SPLAsh
Message-ID: <[e-mail]>
In-Reply-To: Daryl Spitzer's message of 16 Jan 92 20:38:22 GMT <[e-mail]>
Newsgroups: fa.think-c
Lines: 3
Date: 30 Jan 92 08:34:37 GMT

I'm a member, and consider it to be a decent programmer's
magazine.  It's production schedule is a little erratic,
but then, so is mine.










Path: ucivax!gateway
From: [e-mail] (Jonas Barklund)
Subject: Bug in fprint with minimum field width?
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 50
Date: 30 Jan 92 08:53:36 GMT

The program below contains the lines

  printf("%5d", value);
  width = 5;
  printf("%*d", width, value);

which are said in Harbison & Steele, 3rd ed., to result in the same
output.  Under Think C 5.0 they do not; in fact neither of them
produces the expected output.  Here is the full program.

#include <stdio.h>

void main()
{
  int width;
  int value = 42;

  printf("%5d", value);
  width = 5;
  printf("%*d", width, value);

  putchar('\n');

}

When run with Think C it produces the following output:

    05

(without a trailing newline).

When run with, for example, gcc on a SUN it produces the following
output, which is what I would expect.

   42   42

To make things even worse, when I add the line

  fprintf(stderr, "mu!\n");

after the call to putchar, the program crashes with an illegal
instruction exception. This indicates that the I/O system gets
severely damaged. (Under gcc it prints "mu!" on the console, as
expected.)

I have not applied the 5.01 or 5.02 upgrades. Is this problem fixed in
one of them?

Jonas Barklund, Computing Science Department, Uppsala University
Email [e-mail], phone [phone], fax [phone]










Path: ucivax!gateway
From: [e-mail] (Jonas Barklund)
Subject: Bug in fprint with minimum field width?
Message-ID: <[e-mail]>
In-Reply-To: Jonas Barklund's message of Thu, 30 Jan 92 09:53:15 +0100 <[e-mail]>
Newsgroups: fa.think-c
Lines: 7
Date: 30 Jan 92 09:15:44 GMT

Sorry, my mistake. By accident I had turned on "4 byte ints" but was
using the usual ANSI library. I really wish that one could be told
automagically that one's choice of ANSI library is incompatible with
one's choice of int width. Then I would love Think C even more...

Jonas Barklund, Computing Science Department, Uppsala University
Email [e-mail], phone [phone], fax [phone]










Path: ucivax!jhummel
From: [e-mail] (Joseph Edward Hummel)
Subject: Re: Bug in fprint with minimum field width?
Nntp-Posting-Host: wave.ics.uci.edu
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Reply-To: [e-mail] (Joseph Edward Hummel)
Organization: UC Irvine Department of ICS
Lines: 59
Date: 30 Jan 92 09:19:51 GMT
References: <[e-mail]>

In article <[e-mail]> [e-mail] (Jonas Barklund) writes:
>The program below contains the lines
>
>  printf("%5d", value);
>  width = 5;
>  printf("%*d", width, value);
>
>which are said in Harbison & Steele, 3rd ed., to result in the same
>output.  Under Think C 5.0 they do not; in fact neither of them
>produces the expected output.  Here is the full program.
>
>#include <stdio.h>
>void main()
>{
>  int width;
>  int value = 42;
>
>  printf("%5d", value);
>  width = 5;
>  printf("%*d", width, value);
>
>  putchar('\n');
>
>}
>
>When run with Think C it produces the following output:
>
>    05
>
>(without a trailing newline).
>
>When run with, for example, gcc on a SUN it produces the following
>output, which is what I would expect.
>
>   42   42
>
>To make things even worse, when I add the line
>
>  fprintf(stderr, "mu!\n");
>
>after the call to putchar, the program crashes with an illegal
>instruction exception. This indicates that the I/O system gets
>severely damaged. (Under gcc it prints "mu!" on the console, as
>expected.)
>
>I have not applied the 5.01 or 5.02 upgrades. Is this problem fixed in
>one of them?

I'm running 5.02, and THINK C works exactly as gcc does (as it should
in this case).  I can't explain the behavior you saw, except that you
should upgrade :-)  Actually, I suspect it is something else... (like
old version of ANSI library in your project?)

  - joe

--
Joe Hummel
ICS Graduate Student, UC Irvine
Internet: [e-mail]










Path: ucivax!gateway
From: [e-mail] ("Russell S. Finn")
Subject: Re: Creating Windows
Message-ID: <[e-mail]>
In-Reply-To: Your message of "30 Jan 92 03:41:01 GMT."
             <cdVrC=W00WC=[e-mail]>
Newsgroups: fa.think-c
Lines: 26
X-Mts: smtp
Date: 30 Jan 92 11:37:11 GMT

> >Secondly, there already are functions to create panes (and many
> >objects that descend from them) from resources; see the definition of
> >CPane::IPaneRes (which uses a 'Pane' resource), ...
>
> I know about this.  What I'm interested in doing is making a resource
> that says 'put a pane of type CMyPane at this rect, and type CMyButton
> at this rect'.  Hence my problem is how to take the name of the class
> ('CMyPane'), and create an object of that type on the fly.  Other
> compilers have a method to create an object by name (a new() that takes
> a Str255 as the parameter).  This is the ability that I'm trying to get.

Sorry, I must have misunderstood what you were asking.

THINK C 5.0 has this capability also, with the "new_by_name" function
(it takes a char * instead of a Str255, but this *is* C after all :-).

For an example of using this, you may want to take a look at the
implementation of the CDLOGDirector class in the THINK Class Library
version 1.1, which has the ability to create a pane of an arbitrary
class in a dialog by specifying the name of the class in a static text
item in a 'DITL' resource.  (You'll have to read the source; it's one
of the "extra" undocumented classes.)

-- Russell S. Finn
[e-mail]











Path: ucivax!gateway
From: [e-mail] (Daryl Spitzer)
Subject: Re: Creating Windows
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 22
Date: 30 Jan 92 17:38:04 GMT

> >Secondly, there already are functions to create panes (and many
> >objects that descend from them) from resources; see the definition of
> >CPane::IPaneRes (which uses a 'Pane' resource), and the discussion of
> >this topic in an early chapter of the Object-Oriented Programming
> >Reference (I don't have it in front of me, but it's the "How to use
> >the TCL" chapter -- 6, perhaps?).
>
> I know about this.  What I'm interested in doing is making a resource
> that says 'put a pane of type CMyPane at this rect, and type CMyButton
> at this rect'.  Hence my problem is how to take the name of the class
> ('CMyPane'), and create an object of that type on the fly.  Other
> compilers have a method to create an object by name (a new() that takes
> a Str255 as the parameter).  This is the ability that I'm trying to get.

What you're looking for is new_by_name.  See CDLOGDialog::AddOverloadedItem.
The NewClassDemo has some good examples.
--
-------------------------------------------------------------------
 Daryl Spitzer                    "Life isn't just, life just is."
 Vancouver, Canada                         -- Me  (I think.)
 [e-mail]
-------------------------------------------------------------------










Path: ucivax!gateway
From: [e-mail] ("Mr. Neb")
Subject: (none)
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 10
Date: 30 Jan 92 21:23:56 GMT


    Has anyone found a "nice" way to create a text editor without using
TextEdit?  I have been thinking about the problem for a few days; I have some
vague idea of how I _could_ get it to work if I tried, but I am not sure
about how to handle certain functions.

    Does anyone out there have a method that they might like to share?

    Thanks,
        Mr. Neb










Path: ucivax!gateway
From: [e-mail] ("Mr. Neb")
Subject: (none)
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 1
Date: 30 Jan 92 21:25:20 GMT

please add [e-mail]










Path: ucivax!gateway
From: cmiller@laurel (Craig Miller)
Subject: Re: The SPLAsh Story?
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 94
Date: 31 Jan 92 16:38:29 GMT

Greg Dow of SPLAsh (Symantec Programming Languages Association) has
replied to my letter of concern over delays in receiving issues
of the SPLAsh journal.  These concerns were due to my own experience
and from comments made by others over the Think-c mailing list.
The following letter is posted with his permission.

-----------------------------------------------------------------------
Craig D. Miller, Computer Programmer          \  [e-mail]
Scientific Reasoning Research Institute (SRRI) \      tel. [phone]
306 Hasbrouck Lab                               \
University of Massachusetts, Amherst, MA  01003  \                  USA
-----------------------------------------------------------------------

From [e-mail] Wed Jan 29 06:53:09 1992
Message-Id: <[e-mail]>
Subject: Re: The SPLAsh Story?
To: [e-mail]
From: [e-mail] (Symantec Programming Lang Assn,UG)
Date: 29 Jan 92 10:42 GMT

Craig,

The next issue of THINKin' CaP (Issue #4) is running behind schedule.
We are still completing and debugging the software for some of the
articles.
I apologize for the delay, but hope you can sympathize with the
difficulties
in getting software done on time. The issue should be in the mail by
the
end of February.

As a tangible form of apology, I will send you a complimentary copy of
the
Winter 1991 back issue. You will still receive four additional issues
on
your subscription, although it will probably take longer than one
year.
If this situation is not acceptable, notify me and I will issue you a
full refund.

You made a comment about hearing "stories of similar non-communication
via email." Do you mean that others have sent you e-mail about lack
of communication from SPLAsh? Or do you mean that others have said that
SPLAsh has not responded to e-mail messages? I do try to respond to all
e-mail messages, but sometimes mail bounces and I am left with no way
to communicate with the sender.

To answer your other questions:

Who are you?
  I am a self-employed Mac programmer.

What have you done?
  I wrote the original THINK Class Library under contract for
  Symantec.

What are you doing?
  I am working on a couple Mac programming projects; pieces of the code
  I write will appear in articles in the journal.

  I run the Programmers group at BMUG (a non-profit Mac users group
  in Berkeley, CA) and we have meetings every other week. This year, I
  am also Chairman of BMUG and I spend a couple hours each day
  overseeing
  the finances and operation of this group (which has 10,000 members
  and
  12 employees). All this work is as a volunteer.

What are your plans for the future of this association?
  I hope to get a better handle on things, so that I can produce the
  journal in a more timely fashion. I am running SPLAsh mostly as a
  service to programmers. I receive no salary or compensation from
  SPLAsh,
  and in fact invested a few thousand dollars of my own money to get
  the
  group started.

  Once the journal is under control, I'd like to explore other
  services,
  such as hosting conferences and conducting classes.


I understand your disappointment and can only ask for your patience. I
underestimated how difficult it was to produce a quarterly journal. I
am
not trying to cheat or swindle anyone. I believe I have fairly resolved
all complaints, either by sending free back issues or issuing full
refunds (with interest in some cases).

-- Greg Dow
-- SPLAsh













Path: ucivax!gateway
From: [e-mail] (Charles Mead)
Subject: SPLASH
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 6
Date: 31 Jan 92 20:21:24 GMT


How does one sign up for Splash?  I read the response to Craig Miller's
note and feel that I'd like to be a part of this group, whether it publishes
on time or not.

charlie mead